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1.0 PURPOSE 


The Environmental Control and Life Support System (ECLSS) Advanced Automation 
Project has three primary tasks to: 1) determine which software processes in the ECLSS are prime 
candidates for expert system technology, 2) determine the strategies necessary for developing and 
integrating these systems into the ECLSS project, and 3) develop expert systems for the ECLSS 
domain, and demonstrate their value and integrability.^ The University of Alabama in Huntsville 
(UAH) is the prime contractor for the initial requirements generation phase (Phase I) ot the ECLSS 
Advanced Automation Project. The objectives of this contract are to: 

1) Use "divergent thinking" in reviewing the baselined ECLSS and reviewing successful 
related expert system approaches to generate a descriptive list of expert system 
candidates, 

2) Evaluate the expert system candidates using specific criteria, 

3) Using the requirements of the expert system candidates and knowledge ot the baseline 
ECLSS software and hardware architecture, develop a software hooks and hardware 
scars list for future implementation of the expert system candidates, and 

4) In parallel, develop a potable water recovery FDIR manager in order to drive 
requirements and to show a proof of concept demonstration. 

In fulfilling this purpose, we have prepared this report, UAH Research Report No. 823 
which is the final report of the "ECLSS Advanced Automation Preliminary Requirements", and a 
second UAH Research Report No 824 titled "A Diagnostic Prototype of the Potable Water 
Subsystem of the Space Station Freedom ECLSS." 1 ^ 

In this document, a description of the total ECLSS system has been pulled together from 
the available publications on ECLSS and Advanced Automation. The description of the hardware is 
presented in a top down format, the lowest level of which is a functional description ot each 
candidate inplementation. For each candidate implementation both its advantages and disadvantages 
are presented. From this knowledge it has been suggested where expert systems could be used in 
the diagnosis and control of specific portions of the ECLSS. A process to determine if expert 
systems are applicable has been presented, and where applicable, how to select the expert system. 
A section on "Concerns" has been included which describes the consideration of possible problems 
or inconsistences in the knowledge or workings of the subsystems. An annotated bibliography of 
these publications is presented in Appendix A. Finally this report presents in Appendix C the 
Hooks and Scars Document and in Appendix D a dictionary of the acronyms and terms used in 
ECLSS. An index is included for ease of reference. 
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2.0 CONCERNS 

In this section we present some concerns and observations that have resulted from our examining 
the ECLSS system from an overall system viewpoint. 

2. 1 Concerns Regarding System Hardware 

It is very difficult to provide expert fault diagnosis for a that is still in design. Only a limited 
amount of test data exists and expertise is spread over many vendors and subsystem designers. For 
example, no test team has had a chance to evaluate the prototype potable loop hardware in an 
integrated configuration for an extended period. The phase III Core Module Integration Facility 
(CMIF) testing is just beginning. Other components of Space Station ECLSS are in similar 
condition of development. Without such data and expertise about a specific configuration and set 
of technologies, expert systems development must proceed with computer models for generating 
simulated "test" data. ECLSS Systems are complex, and while still under development, they are 
incompletely defined. This proof of concept study illustrates the parallel development of KBS 
software and system hardware, that is necessary for the efficient and successful implementation to 
proceed. 

There will always be compromises in any design project. Certain trade-offs in launch 
weight versas system complexity and versatility will be inevitable. One such design trade-off is of 
special concern for knowledge based system application. The ability of a KBS to detect and 
diagnose faults is directly related to the number and complexity of the sensors which supply the 
KBS with data. It may be unreasonable to propose that instrumentation sufficient to automatically 
diagnose all possible faults be included in designs. The weight, power and added system 
complexity may be a poor trade for the relatively small amount of crew time saved by such a 
system. Conversely, minimal instrumentation would limit KBS diagnostic solutions to more 
simple cases. If KBS applications for the Space Station Freedom are to be successful, some 
attention must be given to the type, number, and location of sensors throughout the design 
process. This will allow the KBS to diagnose a significant number of faults with the associated 
savings in crew time, without severe weight, power, and system complexity problems associated 
with "over instrumentation". 

Development work should be directed toward producing more stable sensors with self 
check and auto-calibration capability. A quite ingenious sensor for O 2 partial pressure has been 
developed for use in the Atmospheric Control and Supply (ACS) subsystem 76 . Similar sensors 
for pH and conductivity should also be developed or KBS diagnostics may produce messages such 
as "check pH sensor #12 calibration". Monitoring possible system contamination by 
microorganisms should be a thrust area in sensor development. Current conventional microbial 
assays are too slow (hours to days) to control such a small scale reclamation system. By the time 
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some these conventional analyses are complete, the system may be profoundly contaminated and 
require a substantial amount of crew time to disinfect and restart. In the absence of some form of 
near real time monitoring, a KBS can only alert the crew to process conditions which "might' lead 
to microbial contamination, such as low temperatures in a heat exchanger/sterilizer or inadequate 
iodine residual. These conditions may or may not result in increased microbial populations. Also, a 
system operating within specifications with regard to chemical and physical parameters may 
experience a microbial population increase. Without any form of automated microbial monitoring 
KBS diagnosis is severely limited to issuing warnings when microbial control systems are 
operating outside optimal levels. 

Organic contaminant monitoring is another area where additional development may be 
beneficial. Astro has produced a UV absorbance monitor which provides a continuous 
measurement of some types of organics. This instrument has several advantages over conventional 
oxidation/ IR absorbance instruments which only operate in batch mode and require aggressive 
reagents. However, many organic compounds including many which are toxic do not absorb in the 
UV region. In addition, these monitors are only useful for low level (ppb) measurements. A 
multiple wavelength instrument using a photodiode array detector might be capable of determining 
more accurately the particular classes of contaminants present. Likewise, new developments in 
surface acoustic wave detectors might also prove to be effective monitors for difficult classes of 
organic contaminants. 


2.2 Documentation 

During the project we have examined a great deal of the available documentation for 
ECLSS. Unfortunately, this process has proved to be inefficient. What is needed is a central index 
to all of the documents about the system, the latest updates to the documents, documents that are 
no longer usable, etc. In short a full text database that is available and on-line is needed. Most 
publications are composed on a computer. The word processing or document processing software 
can generate both plain ASCII files and indexes. A large computer network with appropriate 
software should be able to use this and assemble a database. The database should include both 
published reports and internal NASA reports. A separate section should be set aside for news and 
presentations. At a higher level of functionality, the database could incorporate hypertext browsing 
links. Such links would allow the user to move among the documents in terms of the context of the 
document being browsed, thus coordinating the distributed information. 

Without a documentation database a great deal of time and money is put into locating 
documents, finding related documents, actually securing the document, reproducing the document, 
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reading around the document to find the information, etc. In the end much effort is wasted since it 
either duplicates information in other documents, or is simply out of date. Improving the 
efficiency with such a documentation database would be of great value in knowledge acquisition, 
knowledge management, and design knowledge capture. 


2.3 Knowledge Management 

In building any sort of system, whether it is a traditional system or an expert system, the 
knowledge that is incorporated into the system must be managed. The management of the 
knowledge is a difficult task, but one that technical writers and documentation specialists have had 
to deal with for many years. The resources of these individuals should be solicited in building a 
knowledge management system. 

A knowledge management system is a system that allows access to representations of 
knowledge and provides for the updating of that information. The development of standard 
templates for items ihat can be conceptually represented as frame, scripts, rules, flow charts, etc 
would serve to ensure the ability to gain access to knowledge that is needed in the development of 
any system, but especially a knowledge based system. The knowledge representations that are 
managed by such a system would form a basic template for others working on similar or connected 
knowledge structures. 

Without such a system, knowledge acquisition may remain an idiosyncratic and solitary 
process. This would still be true even if automated tools were used for knowledge acquisition. If 
the knowledge cannot be put into a common representational scheme, then it will be idiosyncratic. 
If the knowledge cannot be shared, then it will remain with the individual. The benefits of 
development of a knowledge management system are that any individual can use any tools that he 
or she likes just so long as it produces representations that can be added to the knowledge base, the 
use of a knowledge management system will encourage cooperation among all knowledge 
acquisition teams, and, finally, the development of a knowledge management system will provide 
for an effective way of checking the consistency or compatibility of various knowledge driven 
projects. Ideally, such a system would be tied to the documents base, and this would provide the 
mechanism for linking the knowledge producers to the knowledge representers. 
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2.4 Knowledge Tools 


The development and ready availability of sophisticated knowledge tools is clearly needed. 
Object oriented programming, multi-agent systems, blackboards, opportunistic inferencing, and 
many other conceptual devices are needed if good knowledge based software is to be produced. 
Without these tools not only is what can be done limited, but that what will be done is to force a 
system design into a particular style of manipulation that may make it difficult to understand and 
maintain the system in the future. 

The drive for Ada was motivated by these concerns. But even if Ada is the common 
language for all software, it will not affect the intelligibility and maintainability of the knowledge in 
the system. Even if CLIPS is rewritten into Ada and if this increases the maintainability and 
intelligibility of the CLIPS system, it will not increase the maintainability and intelligibility of the 
knowledge that CLIPS is designed to manipulate. 

Much of the work in Artificial Intelligence (AI) is being done on LISP machines. It seems 
reasonable to think that a special LISP system may be able to address some of the knowledge tasks 
better than other sorts of systems. It may also be that the tasks might be done more cost effectively 
on a LISP machine since the cost of converting from a LISP based system to a more traditional 
system would be avoided. 


2.5 The Distributed Database On Space Station 

The idea of a distributed database system for the Space Station is a great idea. 
Unfortunately, one might reasonably predict that the system will become overloaded as everyone 
developing software seeks to take advantage of it. In ECLSS there is a great deal of information 
that could conceivably be loaded into the database. This approach would be ideal for facilitating 
exchange between ECLSS support software and other ECLSS units. However, this approach may 
also overload the database system, especially if all sensor data is sent to the database, a historical 
record is kept, and the number of sensors is increased. Thus, some policy governing the use of the 
database system is needed. Alternatively, the processors and networks can be enhanced. 

2.6 Specific Concerns 

It is not completely clear how the subcomponents of the ECLSS will communicate. In 
particular it seems that the Temperature and Humidity Control (THC) and Water Recovery and 
Management (WRM) subsystems would need to communicate with each other about what to expect 
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and what is needed. For example, the Potable Water system may need to know that THC does not 
anticipate generating the nominal volume of condensate. Another example may be the way in which 
the products of a fire could affect the operation of the potable system. 

It appears that more attention has to be given to the way in which simulations may provide 
an important “look ahead” in reasoning about the state of the system. One of the things that a 
simulation might allow is for the anticipation of problems or difficulties. 

Attention also needs to be given to the scheduling of human activities. Various human 
activities can increase the amount of condensate being produced, and the health ot the crew can 
lead to increased demands on the system. Some of these activities if known could be used in an 
automated planning system. Another issue is the number of crew members. It the number varies 
over time the system may need human attention at various points. For example, if the number of 
crew members is over a specified number, it well be necessary to change the unibeds more 
frequently. 

Information concerning the operation and effeciency of the individual unibeds, other than 
the first unibed was not found. If each bed is assumed to generate the same proportionate effect as 
the first, unrealistic values are generated. Therefore a more detailed examination of the operational 
efficiency of multiple unibeds in the multifiltration unit needs to be performed. 

It has been difficult to gain an accurate understanding of the ECLSS software since the 
general philosophy of the ECLSS software context diagrams has not been clearly presented. 

It is not clear that the operations on potable and hygiene water are significantly different. If 
they are not, then it might be good to unify the software for these subsystems in the same way that 
the water quality software has been unified. 

We could not locate any published accounts of what managers and users might want the 
software for ECLSS to do. An investigation of what the users might want in the way ot advanced 
automation is needed. While it is clear that the users appear to want the routine tasks to be 
automated, there does not appear to be a clear line between the routine and the unusual. 

Also there needs to be a clearer specification of which parts of the ECLSS software will be 
ground based and which will be station based. This is important since there seems to be no 
requirement that ground-based software must be in Ada. Thus, ground based software could take 
advantage of already existing tools. Also this would raise the issues of ground to station 
communication links, speed, and protocols.These need to be more clearly defined. 

Some attention should be given to the various user models to be incorporated in the 
software. Suppose the crew member who was an ECLSS specialist was injured or ill. Some other 
crew member would need to fill in. It might be reasonably assumed that this crew member is not as 
well versed in specific ECLSS operation as the unavailable crew member. If this is so, the 
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replacement user of the ECLSS software may need a different level of help than the specialist, 
especially in terms of display that the system generates. 

One of the advantages of using standard inference engines, and other standard AI software 
on the Space Station, is that various updates and refinements to the knowledge components can be 
sent to the Station and installed on the system. This could be as simple as erasing a file and loading 
a new one. This, however, would seem to become viable only if there is a specification of the 
standard software on the Station and the standard knowledge representation schemes used by the 
software. It is not clear to us what this standard is. To the degree that there is such a standard, it 
appears that it is given in the structure of CLIPS. This should be clarified. 

The criteria for assessing potential advanced automation efforts need to be made more clear. 
Since the criteria act as a template for generating candidates, these criteria are important and must 
be clearly defined. 
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3.0 INTRODUCTION 


3.1 ECLSS Science and Technology 

The Space Station Freedom's design includes a number of modules, airlocks, and nodes 
which are docked together to form a pressurized habitat for manned operations. The function of the 
Environmental Control and Life Support System (ECLSS) is to provide a shirt sleeve 
environment for the crew, as well as providing the water and atmosphere necessary to sustain 
them.^l in designing the ECLSS for the manned Assembly Complete (AC) Station the design 
must include closed loop air and water systems to accommodate the extended duration ot the 
missions and to avoid having to constantly resupply. This is particularly important in light ot the 
fact that Space Station Freedom operations will not have readily available escape capability. 88 

The ECLSS comprises six major subsystem groups, as pictured in Figure 1, which include 
Temperature and Humidity Control (THC), Atmosphere Control and Supply (ACS), Atmospheric 
Revitalization (AR), Fire Detection and Suppression (FDS), Water Recovery and Management 
(WRM), and Waste Management (WM). These subsystems are described in Section II, and their 
functional interrelationships are summarized in Figure 2.88 

The hardware/software control architecture is built using components ot the Data 
Management System (DMS). Rack level controllers will control and monitor all the subsystems 
contained within each ECLSS rack. The element manager controls functions in the elements. The 
system level controller, partially on-board, partially on the ground, will perform inter-element 
functions; performance and trend analyses; and system fault detection, isolation, and recovery. It 
will also interface with the overall station level DMS Operations Management System. 8 8 
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ATMOSPHERE 


Source: NASA. 1989. "Environmental Control and Life Support System Architectural Control Document," NASA 
Marshall Space Flight Center, February 15, 1989. 5 


Figure 1. Space Station Environmental Control and Life Support System (ECLSS) Overview. 
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Figure 2. Environmental Control and Life Support System (ECLSS) Schematic 
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3.2 ECLSS Information System^, 32 


The software for the ECLSS incorporates several different levels of functionality and 
processing. This section of the report will focus on the way in which the software leads from the 
ECLSS Software Support module (now called ECLSSMGR) to the potable water software 
(P0TH20). No attempt is made in this section to give an exhaustive account of the software for 
each ECLSS subsystem. However, the discussion of the ECLSS Support Software will apply to 
all of the subsystems. 
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The ECLSS Support Software is intended to aid in the administration ot the subsystems ot 
the ECLSS. It is through the ECLSS Support Software that the Space Station’s HABOMAand 
STADIS software are informed of the conditions and needs of the ECLSS system. It should be 
noted that the organization of the software is a logical organization and not a physical organization. 
It is not a question of where the software is located, but of what the software does. Thus, the 
software for the subsystems and the ECLSS support software may reside in physically distinct 
computers, or the same computer. 


The context diagram (See 
Figure 3) indicates the ways 
in which the ECLSS Support 
Software (now called 
ECLSSMGR) coordinates the 
activities of its subsystems 
(THC, AR, ACS, FDS, 

WRM, WM) and passes 
information to the habitat 
module level software 
(HABOMA) and the station 
level software (STADIS). 

(Larger context diagrams 
appear at the end of this 
report.) Each subsystem of 
ECLSS is represented in the 
diagram. At this context level, 
each subsystem can be 
thought of as taking in sensor 
data and, on the basis of its 
code and communication with 
the ECLSS Support 
Software, issuing commands 
to the hardware. Taken in this 
way, the software packages 
for each of the physical 
ECLSS subsystems represents the actions that ought to take place given certain sensor readings 
and communication with the ECLSS Support Software. In terms of the context diagram at this 
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level, there is no direct communication of the software for the ECLSS subsystems to the habitat or 
station level software. Rather it is the ECLSS Support Software that communicates with those 
software packages. For detailed context diagrams, please refer to Appendix B. 

The ECLSS; Support Software receives commands from both HABOMA and STADIS and 
sends requests and status information to HABOMA while operational data is sent to STADIS. Each 
subsystem sends requests and status information to the ECLSS Support Software, while the 
ECLSS Support Software sends commands to the subsystems. In this way, information traverses 
up and down through the layers of the control software. 

Inside of the ECLSS Support Software are six subcomponents that handle the incoming 
information from the ECLSS subsystems, HABOMA, and STADIS. 

As indicated in the context diagram for the 
ECLSS Support Software, ACTIVATE is the 
central subcomponent, since it issues 
commands to ECLSS subsystems and requests 
to HABOMA. The commands, however, are 
checked before an activation. INHIBIT, 

INHDATA ECLSS, and CMD are the modules 
that check for processes that are inhibited. 

ACTIVATE sends a process name to INHIBIT 
which in turn sends a message to the inhibited 
function list in INHDATA ECLSS. The 
resulting process status is sent to CMD. CMD 
receives requests from all ECLSS 
subcomponents, as well as commands from 
HABOMA and STADIS. CMD indicates 
invalid commands to HABOMA and valid 
commands to ACTIVATE. 


Short Name 

Long Name 

ACTIVATE 

Activate Valid ECLSS 
Process 

INHIBIT 

Process ECLSS Inhibit 
Commands 

INHDATA 

ECLSS 

Inhibited Function List 

CMD 

Verify and Validate ECLSS 
Commands 

ECLSSERR 

ECLSS Fault Detection and 
Isolation 

ECLSSPER 

ECLSS Performance and 
Trend Analysis 

DISPLAY 

ECLSS Display 
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Figure 4. Context Diagram for ECLSS Support Software — ECLSSMGR 


ACTIVATE also sends commands to ECLSSERR, ECLSSPER, and DISPLAY. 
ECLSSERR receives failure data from all ECLSS subsystems and sends critical errors to 
HABOMA and operational data to STADIS. ECLSSPER receives status data from all ECLSS 
subsystems and sends history, performance, and status data to HABOMA and DISPLAY. 
DISPLAY receives display data from all ECLSS subsystems as well as ECLSSPER, and sends 
display data to HABOMA. 
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Water Recovery and Management Subsystem (WRM) 



Figure 5. Context Diagram for ECLSS WRM Software 

As the context diagram for the WRM indicates there are six modules that include both the 
potable and hygiene water systems. These modules analyze and control the water recovery 
functions in terms of the limits set for the subsystem. In general, each unit receives information 
from sensors and various software units, and on the basis this information processing generates 
new data and issues commands and requests. 
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On the basis of commands from ACTIVATE, 

WRMLMT constructs new limit data for 
WRMLIMITS and reports its status to 
ECLSSPER. WRMLIMITS establishes the ranges 
for the main subcomponents POTH20, 

H20QUAL, HYGH20, and URINE. Each of 
these subcomponents receives commands from 
ACTIVATE and sensor inputs from hardware. The 
case of H20QUAL is somewhat special since it 
receives special sensor inputs for iodine, 
conductivity, pH, and TOC (Total Organic Carbon). Additionally, each subcomponent sends 
commands to hardware, requests to CMD, display data to DISPLAY, status data to ECLSSPER, 
and failure data to ECLSSERR. Additionally, H20QUAL sends quality status to POTH20 and 
HYGH20. 

Within WRM, P0TH20 will be taken as an example since the potable water system is the 
focus of the demonstration software produced for the overall effort of this research. The details of 
the demonstration system are presented in UAH Research Report No. 824. It should be 
noticed, however, that the demonstration software overlaps the functionality of POTH20 and 
H20QUAL. In part this is because the physical potable water system overlaps both software 
components, and in part because the potable water design effort is geared to producing water of a 
specified quality. This raises the important fact that the breakdown of software components need 
not match precisely the breakdown of the function of the physical system. In the case at hand there 
seems to be an obvious reason why the software and physical breakdowns do not correspond. 
Although the potable and hygiene water systems are distinct physically, the process of monitoring 
water quality is sufficiently similar that one module (H20QUAL) can satisfy the demands of both 
the potable water system (P0TH20) and the hygiene water system (HYGH20). For reasons of 
economy, the monitoring process is placed in one module rather than in two and shared by both 
subsystems. 


Short Name 

Lonii Name 

WRMLMT 

Set WRM Limits 

WRMLIMITS 

WRM Limit Data 

P0TH20 

Process Potable Water 

H20QUAL 

Process Water Quality Sensor 
Dala 

HYGH20 

Process Hygiene Water 

URINE 

Process Urine 


16 





As indicated in the context diagram, P0TH20 consists of five modules. The central module 
is CHKSTA. CHKSTA receives status information from each of the other modules and issues 
controls to each. Further, CHKSTA provides status information to ECLSSPER. 


Each of the modules that report to CHKSTA act 
on the basis of commands from ACTIVATE, 
limit ranges from WRMLIMITS, and controls 
from CHKSTA, and each module sends its status 
to CHKSTA and ECLSSPER, requests to CMD, 
failure data to ECLSSERR, and display data to 
DISPLAY. The modules differ in the statuses that 
are input and the hardware commands that are 
output. RECH20 receives sensor statuses from 
the liquid, speed, pressure, pressure transducer. 


Short Name 

Long Name 

CHKSTA 

Monitor Subsystem Statuses 

RECH20 

Monitor and Control Receiving 
Tank and Pump 

PURIFY 

Monitor and Control the 
Purification Process 

STORAGE 

Monitor and Control Potable 
Water Storage 

QUALITY 

Monitor the Water Quality 
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and flow meter, as well as statuses from pump and valve, and sends commands to pump and valve 
as well as passing the pump status to QUALITY. PURIFY receives sensor statuses from pressure, 
pressure transducer, and temperature, as well as the status from heater, and sends commands to 
heater. STORAGE receives sensor data from liquid sensor, as well as status from valve, and sends 
commands to valve. QUALITY receives sensor status from temperature, as well as statuses from 
pump, valve, and H20QUAL, and sends commands to valve. 

Summary 

The ECLSS software is a layered collection of software modules that may be thought of as 
a logical hierarchy that can be located in physically distinct computers. Although only the path from 
the ECLSS support software to P0TH20 has been traced, analogous tracings could be produced 
for the other ECLSS subsystems. In this report’s discussion of the application of artificial 
intelligence techniques to ECLSS software, this analogy will be assumed. 
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3.3 Evaluation of Candidates for Advanced Automation 


3.3.1 Introduction 

The decisions to implement advanced automation projects using expert systems (ES) 
techniques are similar to other such decisions, but there are some significant differences. Many of 
these differences are a result of the way in which ES is perceived and received, and in the nature of 
the tasks of these software systems. Various schemes have been devised to make decisions on 
whether or not to implement systems using ES technology. These schemes specify the factors that 
should be considered in making the decision. 

Two important schemes for making the decision to implement an ES have been constructed 
by Slagel and Wick^ and the group of Knowledge Based (KB) systems experts enlisted by 
NASA's Space Station Level I Strategic Plans and Programs Division (hereafter referred to as the 
"KBS Group") that constructed the Space Station Advanced Automation Study Final Report 
(SSAA). 9 While there is significant overlap between the two schemes there are also some 
differences. Each scheme has merit. This section will indicate where specific problems may arise. 
This section will also make three recommendations concerning the evaluation of the candidate 
systems in evolving domains, knowledge acquisition, and the types of situations in which various 
artificial intelligence technologies may be applied. 


3.3.2 Comparison of the Schemes 

Although both the Slagel and Wick scheme and the SSAA scheme seek to address the same 
sorts of issues, they differ in the way they construct their appraisals. 

The Slagel and Wick scheme provides a computational space in which each consideration 
influences the final judgment. Thus, a candidate that scores low in a particular area might still be 
accepted. Given the weights and the function that computes the final candidate value, a final value 
is generated. There is no hierarchical ranking of considerations accept that which is implicit in the 
weights and computation function. In this sense none of the characteristics are essential. 

The SSAA scheme provides a hierarchy in which essential considerations must score 
highly before other considerations are appraised. In this sense the general A level criteria would be 
at the top of the hierarchy and the other criteria would fall lower in the hierarchy. Thus, if a 
candidate did not do well for the general A level criteria there would be no need to continue the 
decision process. 
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There are merits to both approaches. The Slagel and Wick scheme provides a way ot 
creating a global evaluation of a candidate, while the SSAA scheme provides a way for the sponsor 
of the project to establish demands. Further, it would seem natural for the proposer of the 
candidate to rely more on the Slagel and Wick scheme that the SSAA scheme. This would be so 
since by adjusting the weights and computation function the proposer of the candidate could 
establish the value of the candidate in the terms that he sees to be important. On the other hand, the 
SSAA scheme would be favored by the sponsor, since it allows the sponsor to clearly indicate 
what conditions must be satisfied if the sponsor is to support the project. 


3.3.3 Recommendations 

Both the SSAA scheme and the Slagel and Wick scheme may be used. It is important that 
in the decision process it be clearly identified which scheme is being used. If this is not done, 
confusion and poor judgments will follow. In the UAH Research Report Number 824 ^ on the 
demonstration system for the potable water subsystem of ECLSS, the way in which these 
schemes might be applied and the way in which differences of opinion can be generated was 
examined. It should be noted that the differences in opinion are reasoned differences. In such a 
situation it will be important to be clear about what is being claimed, and attempt to identify 
common grounds. 

The following are specific recommenations about these schemes and their use: 

The first specific recommendation is that for systems such as the ECLSS, a special set ot 
procedures be established for the candidate systems. As noted in the comments many ot the 
subsystems of ECLSS are currently being developed. This means that any value assigned on the 
Slagel and Wick model or any judgment made on the SSAA model may change as the subsystem 
changes. This is extremely important. If the value of ES technology, (and especially rule based 
systems) is in general accepted as valuable, and if independent judgments are to be made about the 
value of tools and shells, then the real focus of the schemes will be the domain to which these are 
to be applied. Unlike many other cases in which the domain and experts about the domain already 
exist, this is not the case with the ECLSS and many other components of the Space Station. Thus, 
even if either of the schemes is accepted as the scheme with which candidate evaluations are to be 
done, modifications must be made and special procedures added to reflect the evolutionary 
character of the domains and candidates. 

The second specific recommendation is that considerations or criteria be added to focus on 
the problems of knowledge acquisition. It is generally recognized that knowledge acquisition is an 
extremely difficult task. To some degree the questions articulated by Slagel and Wick address this 
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difficulty more that the criteria proposed in the SSAA. Without addressing the knowledge 
acquisition issues, the judgments made about candidates may well be flawed. Consider for 
example, that at most two of the criteria proposed by SSAA address the knowledge acquisition 
problems. In terms of an overall judgment, therefore, a candidate may rank very high even though 
the domain is not sufficiently defined and the experts are both antagonistic and of divergent 
opinions. This may lead to the failure of the candidate project. 

The final recommendation is that more general issues of artificial intelligence (AI) be 
considered in making evaluations. The schemes seem to focus only on rule based systems. 
However, what counts as an expert system and the available artificial intelligence technologies are 
changing rapidly. Thus the following taxonomy is proposed as a guide. 

There are several different situations in which AI technology can be added to ECLSS. For a 
description of ECLSS software, see section 3.2 of this report. As a matter of convenience and 
uniformity the following classification scheme is proposed: 


Type 

Description 

Example 

Type 1 

Coordination/Diagnosis/ Action for multiple 
intermediary units 

ECLSERR ! 

Type 2 

Coordination/Diagnosis/ Action for non- 
intermediary units 

P0TH20 

Type 3 

Pattern analysis of data 

QUALITY 


Type 1 situations can be thought of as situations in which a unit processes the data of other 
units and to which messages are transmitted. Within the ECLSS, ECLSERR would seem to be 
such a situation. From the point of view of the ECLSS all subsystems report errors to it. Its actions 
are then directed either to other ECLSS components or to HABOMA. From the point of view of 
the ECLSS subsystems, ECLSSERR is the highest level unit. All ECLSS subsystems are 
intermediary. An intermediary system is one which reports to a higher system and itself receives 
reports from its subsystems. For example WRM and P0TH20 are intermediary. 

What is special about the Type 1 situation is the domain it engages and the functions it must 
perform. The domain is not the domain of the hardware in action, but the information generated by 
intermediary units about the hardware in action. Thus, P0TH20 might send up error data to WRM 
and then to ECLSSERR. ECLSSER could either handle the problem or pass the problem outside 
of the ECLSS to HABOMA. ECLSERR would ideally need to understand data and messages sent 
from the intermediaries, and be able to send messages back to the intermediary and to HABOMA. 
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Thus, what ECLSSERR operates on is information generated by other software units. It may be 
assumed that the information given to it in this Type 1 situation has been processed, interpreted, 
and symbolically categorized, and that the ECLSERR must be able to decode it. 

The tasks that must be performed in the Type 1 situation are complex and symbolic in 
nature, heterogeneous in character, and require knowledge about the operation of many systems 
and how those systems communicate information. These characteristics make Type 1 situations 
ideal candidates for specifically constructed programs that can perform parsing, string 
construction, frame analysis, rule application, and other operations for which a LISP processor 
would seem ideally suited. If this is so, then such situations would call for a hardware scar for the 
introduction of a LISP processor and software hooks to allow for other units to communicate with 
it and for it to communicate with other units. Ideally, this would also include specifications for 
how to add words and units to the LISP based system, a more or less standard syntax for 
messages, and sufficient administrative support to keep the project at the level of symbolic 
manipulation of information, data, plans, diagnoses, explanations, etc. 


r 

K. 


Highest Unit 
Type 1 


\ r 

Intermediary Unit 
Type 2 




J 


J 


r 

v 


_ ^ 

Lower Level 
Units, Perhaps 
intermediary 


J 


r 


Lower Level 
Units, Perhaps 
intermediary 


J 


Type 2 situations are those situations in which intermediary units can effectively process 
information in a rule form. The intermediary units may receive information directly from hardware 
through a Runtime Object Data Base (RODB) in standard engineering units, from the ECLSS, or 
from subcomponents. The sorts of diagnostic and supervisory tasks perform by the intermediary 
units would tend to be specific sorts of tasks (“Determine if the the sensor data is within in range 
and note what is odd.”) These are closely linked to the physical devices that are running under its 
supervision. In this sense the domain is the process itself. This is an ideal place for a classical rule 
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base system, although frame based systems may also prove effective. 116 It should be noted that 
using a CLIPS-like system for these situations would be ideal since, at least potentially, a CLIPS 
knowledge base could be updated in the same way that an RODB is updated. This would allow 
modification to the hardware and to the general database (on red-line and-yellow line, for example) 
to be reflected in the knowledge base. 

Type 2 situations call for software hooks to allow communication both up and down from 
the units. This may not be that difficult since such channels already exist (see context diagrams). 
However, they might need to be rethought in the light of KBS functionality. Scars do not seem to 
be an issue here, unless it is in terms of on board memory (RAM) in the unit that will do the 
processing, or in the size of the mass storage device (disk) that is serving the processor on which 
the rule based system is running. A far more exotic software hook would be the demand to 
improve the CLIPS to include genuine backward chaining, frames, metarule, demons, stores, etc. 
(See UAH Research Report Number 824 115 ). 

Type 3 situations are the most exotic. These are situations in which the pattern learning and 
matching capabilities of a neural net could be put to good use. Such situations may be important in 
the acquisition of sensor data, the capacity to use the patterns of a neural net as a “redundant” 
sensor, as a store house for the pattern of usage in components, as way of gaining hints about 
incoming or outgoing telecommunications, etc. The point is that other technologies are up and 
coming and may also play a significant role. Although neural nets can run on a 80386, and thus 
are not candidates for scars, a scar may be in order if the neural net software can be thought of as a 
redundant sensor. In this sense the result of the net would have to go to wherever it is that sensor 
input goes. 

The adoption of the proposed taxonomy would allow a more detailed and disciplined 
evaluation of candidate projects while also allowing for a greater range of AI techniques to be 
considered. 


3.3.4 Summary 

In this section the schemes of candidate system evaluation proposed by Slagel and Wick, 
and the SSAA have been examined. Each scheme has merit and it is possible to use each scheme if 
it is made clear which scheme is being used. We have also identified some difficulties in the 
evaluation of candidates that are dealing with domains and expertise that are in evolution. 
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In light of this examination we recommend that: 

• special procedures be established for the evaluation of candidates that are evolving, 

• issues of knowledge acquisition be given a greater role in the evaluation 

• a taxonomy be adopted that allows for both the consideration of a wider range of A I 
technologies and the nature of the different sorts of tasks to which they can be put. 


3.3.5 Detailed Description of Each Scheme 


3.3.5. 1 The Slagel and Wick Scheme 


The Slagel and Wick scheme focuses on several categories of questions that must be 
answered in attempting to generate a reasoned decision to employ ES technology, as summarized 
in the following table: 



Feature 

Component 

Essential 

Users and Management 
(UM) 

Description 

Weight 

Value 


Task 

CD 

Description 

Weight 

Value 


Expert 

(E) 

Description 

Weight 

Value 

Desirable 

Users and Management 
(UM) 

Description 

Weight 

Value 


Task 

CD 

Description 

Weight 

Value 


Expert 

(E) 

Description 

Weight 

Value 


The descriptions are simply identifications of features. Ideally these descriptions include 
some means of operationalizing the feature. The weights and feature values are normalized to 
generate numbers between 1 and 10. This allows various formulae to be applied in the construction 
of the overall evaluation of the candidate project. 
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The particular questions identified by Slagel and Wick are: 
E 


UM1 

Do the recipients of the system agree that the payoff is high? 

UM2 

Do the recipients have realistic expectations? 

UM3 

Is the management committed to the project? 

T1 

Is the task natural language easy? 

T2 

Is the task knowledge intensive? 

T3 

Is the task heuristic in nature? 

T4 

Are test cases available? 

T5 

Can the system undergo incremental growth? 

T6 

Does the task require little common sense? 

T7 

Can the task be done without optimal results? 

T8 

Will the task be performed in the future? 

T9 

Is the deadline for the system relatively open? 

T10 

Is the task easy, but not too easy? 

El 

Does an expert exist? 

E2 

Is the expert a genuine expert? 

E3 

Is the expert committed to the project? 

E4 

Is the expert cooperative? 

E5 

Is the expert articulate? 

E6 

Has the expert been successful at other tasks? 

E7 

Does the expert use symbolic reasoning? 

E8 

Can the expert transfer his or her expertise to others? 

E9 

Does the expert use cognitive skills? 

E10 

Do multiple experts agree? 

Ell 

Is the expert not being especially creative? 
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Desirable Characteristics 


UM4 

Is the management willing to commit time, money, and effort? 

UM5 

Will the insertion into the work place be smooth? 

UM6 

Will the system be able to generate explanations? 

UM7 

Will the system be able to intelligently question the user? 

Til 

Was the task previously identified as a problem area? 

T12 

Are solutions explainable and interactive? 

T13 

Does the task lack real-time demands? 

T14 

Is the task similar to previous KB efforts? 

T15 

Is the task performed at many locations? 

T16 

Is the task performed in a hostile environment? 

T17 

Does the task involve subjective factors? 

E12 

Is the expert unavailable when the system is needed? 

E13 

Can the expert become intellectually attached to the project? 

E14 

Does the expert feel comfortable with the project? 

E15 

Is the expertise loosely organized? 


These questions set out a basic structure for determining whether a knowledge based (KB) 
approach is appropriate. As noted earlier various rating functions could be applied to the values 
generated in response to these questions. Within the Slagel and Wick scheme it is important to 
notice that none of the questions have an essential character. Any of the questions could be set to a 
low or high value without directly affecting the decision to employ an KB technology. An 
alternative is to set out criteria that demand to some degree that characteristics be satisfied. This 
alternative would establish a set of questions to which it is essential to have high values if the 
candidate is to be accepted. This is the approach taken in the Space Station Advanced Automation 
(SSAA) final report. Rather than indicating questions and a ranking function, the report sets out 
criteria for KB projects. 
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3. 3.5. 2 The SSAA Scheme 


The SSAA Final Report^ established various evaluation criteria for the evaluation of 
advanced automation projects. These can be separated in to General, Baseline and Evolution 
criteria. The three kinds of criteria indirectly correspond to the types of Slagel and Wick. However, 
the SSAA scheme does not provide for a general computation. It specifies certain essential 
characteristics that a candidate project must satisfy, if the candidate is to be accepted. Further the 
KBS Group indicated three levels of importance ranked A,B and C. The levels indirectly 
correspond to the attribute values of Slagel and Wick. However, it should be remembered that 
these levels of importance seem to be constructed so that if a candidate does not score well at the A 
level, its scores at the B and C level do not matter. In this sense the SSAA criteria forms a 
hierarchy. 

The SSAA report was generally positive in its appraisal of the potential for ES applications 
to ECLSS: “(particularly water and air regeneration) — major advantages for a KB approach were 
lack of crew experience with new Space Station technology and relative technical simplicity of the 
underlying systems. Major disadvantages were the life-criticality of such a system and lacking 
internal experience or champions (advocates) within NASA.”9 


General Criteria - Level A 

These criteria stand at the top of a pyramid of criteria. They are both the most general 
criteria and the most necessary to be satisfied. In this sense they can be understood as necessary 
conditions for a successful project. It should be understood that even for a potentially successful 
project not all of the criteria need to be satisfied, nor must they all be satisfied to the same degree. 
Thus, it is the massed action of these criteria that need to be satisfied. 

• Presence of a strong user champion 

Comment - A user champion is an advocate who is personally involved and is within the 
sponsoring agency. The SSAA final report indicates that the astronauts would be in favor 
of such a system. This is important. However, since any advanced automation for ECLSS 
would include as users the space life sciences group and system design engineers, these 
groups should also be interviewed. The interviews should focus on both the perceived need 
for such systems and the kinds of features desired. 
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• Presence of a strong management/executive funding champion 

Comment - The executive champion is an advocate committed to ensuring that the 
development process is protected and resources are made available, even in difficult times. 
Although the report indicated that ECLSS is a good candidate it is not yet clear who the 
project champion will be. 

• Strong feeling of participation by all user groups including crew 

Comment - This can only be achieved if the astronauts and others are interviewed and kept 
informed. It would be desirable to have some mechanism by which the end users can teed 
their recommendations to the team that designs and builds the system, therefore allowing 
for maximum performance and satisfaction. 

• Existing expertise and agreement on heuristic solution 

Comment — As the SSAA report noted much of the ECLSS system is currently being 
developed. This means that it will be difficult to identify experts. In this sense the 
evaluation of candidate systems for ECLSS will either receive a low rating, or will receive 
special attention. The reason for this is that in most candidate evaluations both the system 
and the expertise exits. This is not the case for the ECLSS. Thus, a procedure in which 
both the development of the ECLSS system or subsystem and the ES applications are 
appraised during the evolution of the whole system would seem to be needed. 

• Functionality cannot be achieved cost effectively without a knowledge based system 

Comment - The SSAA report provides an illustration of the intent of this criterion. For 
example, ‘Pl-in-a-box’, a three man-year effort on a MacII in Nexpert, would be about 
$250,000. The report indicates that this should be a typical case. On the other hand the 
trend analysis expert running on 5 Sun4 class machines and an optical Local Area Network 
(LAN) under the efforts of a senior computer engineer, senior programmer, and 4 junior 
programmers comes out at $1,000,000 for three years in a 10 man-year effort. In short 
there seems to be a large range in what would count as being cost effective. The 
determination of the satisfaction of this criterion should rest on an economic analysis. 

• Ability to both qualitatively and quantitatively evaluate the success of the application 

Comment - This would be specific to each instance of the KB. The need is for clear criteria 
of what the system is to do and how it is to do it at the outset. Anecdotal evidence is not 
sufficient according to the report. In the case of ES systems that are evolving with the 
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physical system and expertise about it, special procedures for evaluating the satisfaction of 
this criterion may be needed. 

• Ability to demonstrate incremental progress 

Comment - This criteria seems to represent general managerial practice, however in the use 
of KB technology there are some difficulties. The ability to demonstrate incremental 
progress hinges on what is to count as a demonstration. An improvement in the 
organization of the system might make a system run faster while a sudden increase in 
knowledge content might make it run slower. In order to satisfy this criterion some clear 
account of what counts as a demonstration and what counts as incremental progress must 
be established. 

• Potential horizontal generality of application 

Comment - This criterion contains several different issues. On the one hand the generic 
parts of a KB system can be extended horizontally. However, it is very unlikely that the 
most domain specific claims will be able to be extended. In order to satisfy this requirement 
some notion of abstraction is needed, and that will require software tools for support. For 
example, a larger frame based reasoning system may be able to be extended and allow 
some of the knowledge in the frames can be used horizontally. Such systems may prove to 
be rare and may require new software techniques to be developed. In short, this criterion 
should be made more specific in terms of its intent. 

• Availability of test cases 

Comment - Clearly it is important to have test cases available and to use them in testing the 
produced system. However, it should be noticed that too great an emphasis on test cases 
may lead to undesirable results in terms of influencing the methodology of the knowledge 
acquisition, and the type of reasoning system to be employed. Case based reasoning may 
be good even if it does not perform as well as another approach on the test cases. It should 
be noticed that the condition of quantitative and qualitative evaluation can produce answers 
that are at odds with test case results. This possible conflict upon the satisfaction of criteria 
should be taken into account in any appraisal. 

• Ability to firewall the application from doing harm 

Comment - This seems to be a much more technical criterion that the others in this group. 
To firewall the system entails some way in which the system can be turned off. That seems 
to be a design decision that is commensurate with, if not equivalent to, the demand for a 


29 



person to be in the control of the system. If this is the intent, then the demand can be 
satisfied. If on the other hand, the intent is that any such system must also be able to 
diagnosis what it itself is doing, then this becomes a hard problem. It would require the 
system to both reason about other systems and itself. Such systems would be difficult to 
construct would require the cooperation of other software components, and use an 
increased amount of computing resources. 

• Bounded technical complexity 

Comment - It is an accepted principle that KB systems should operate on problems that are 
neither too hard nor too easy. The difficulty with the application of this criterion to the 
ECLSS is that since the ECLSS is under development the appraisal of the the technical 
complexity may change as the system changes. This again indicates the need for some sort 
of co-evolutionary appraisal procedure. 


General Criteria - Level B 

Again these are general criteria to be applied to a project. Their importance is lower than the 
Level A criteria. However, these criteria do raise important issues. 

• High visibility 

Comment — This criterion seems to reflect the political and social dimensions of 
the advancing KB technology, and would not be a criterion for a traditional software 
program. The attempt to satisfy this criterion could lead to compromises in the A level 
criteria. However, since the criteria are hierarchical, no level of visibility, or lack there of, 
should alter the decision at the A level. 

• Model based reasoning approach that allows for multiple uses 

Comment - The suggestion seems to be that while rules are a good knowledge 
representation for many problems, they are neither the only representation, nor the best for 
specific problems. One should also look forward to new techniques, in particular model 
based reasoning. In this sense, CLIPS may very well be an undesirable tool. The 
development of other kinds of systems will depend upon the inclusion of tools in the 
Software Support Environment (SSE). 
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• Automate what people like to do least; the routine; the day-to-day 

Comment - Bureaucratic agents can be of great service. Routine reports and monitoring 
should be automated. This suggests other sorts of application for advanced automation. It 
should be noted, however, that some of these tasks may be either so computational or so 
routine that AI techniques are not required. 

• Capitalize on what has been started. 

Comment — As with several of the other proposed criteria, this criterion seems to be either 
a directive as to the types of projects that ought to be proposed, or a general management 
practice claim. If it is the former it may be unduly restrictive, and if the latter unnecessary. 

• Start with advisory mode and evolve if appropriate to a close-loop system. 

Comment — This seems to be a directive about how to plan the development of a 
candidate, and an injunction against starting with a closed loop system. This might better be 
thought of as a specification rather than a criterion. 

• For space based applications the system should be one that can be put into operation on the 
ground first. 

Comment — This proposed criterion again appears to be a directive, rather than a criterion 
for appraisal. It is also unclear why a well tested system should be put into operation on the 
ground first. If the testing which can take place on the ground, has been done this would 
seem to be sufficient to place the software into an advisory mode on board. Further, putting 
diagnostic software into operation on the ground first seems to be a testing procedure, since 
many of the faults may well have been detected and recovered from on board. 


• Use design knowledge. 

Comment - For the ECLSS there would be a very strong possibility of satisfying this 
criterion if the co-evolutionary strategy is adopted. There are two significant alternatives to 
the capture of such design knowledge. The first is to embed the capture of this knowledge 
within the design of the software system. This may not prove to be an ideal way to 
proceed, since the Knowledge Engineer (KE) would be focused on the acquisition of the 
knowledge related to the projects goal. On the other hand it would allow the KE to have a 
greater understanding and contact with the experts. The second alternative is to establish a 
separate project for design knowledge capture and for the production of advanced 
automation for design. This would have the benefit of being a focused effort that could 
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produce both knowledge and tools that could be used horizontally, but would increase the 
expense of the project since another team would be needed, and may increase interpersonal 
conflict since the experts may overlap and be the focus of two distinct KE groups. 


General Criteria - Level C 

The third level of General Criteria is designed to place the proposed system in the context 
of other projects. 

• The system can be evolved to higher functionality after deployment. 

Comment — This seems to be a specification of the B level stipulation that systems start in 
the advisory mode. 

• The system can use non-ES techniques. 

Comment — It would seem that an ES system if it is to evolve at all must make use of non- 
ES technologies, particularly data bases, networks, and communication systems. If this is 
the intent of the criterion, it is reasonable enough. However, it might also mean that there 
should be a non-ES backup system. This would pose problems. If the non-ES is a good 
enough backup system, then there is no need for the ES unless a specific advantage (speed, 
efficiency) can be shown. Further, the construction of the backup will add to the cost ot the 
project. 


Baseline Criteria - Level A 

The second variety of criteria specified in the SSAA concern the baseline of the system. 
These seem to be intended to capture the conditions that the system must satisfy in order to be 
included in the Space Station Freedom. 

The Level A criteria and the Level B criteria seem to be greater specification of related 
general criteria. 

• Medium to high payoff 

Comment — In order to be clear about this criterion some way of computing payoff is 
needed. 


32 



• Low technical risk 

Comment — Given that the project has a bounded technical complexity, this criterion 
would seem to refer to the calculation of the risk. Some formula should be specified to 
compute the risk, and some scale should be established. 

• Reduction of crew time spent in routine and maintenance functions. 

Comment - There was a positive attitude of crew towards the use of KB systems on the 
Space Station Freedom. They expressed a very strong desire to spend as much time as 
possible on the Space Station carrying out scientific experiments and as little time as 
possible worrying about maintenance and other housekeeping chores . 9 As the SSAA report 
noted, the ECLSS would seem to be a good candidate for this reason. 

• Expected high user acceptance 

Comment — Interviews with users about the candidate, and involvement of the users in the 
design are important factors in satisfying this criterion. 

• Effective ground evaluation prior to deployment 

Comment - In the case of the systems that might be used for ECLSS, this could be satisfied 
by having a tight coupling of the knowledge engineer with the systems engineers. This 
would allow the full ECLSS system and the advanced automation projects to co-evolve. If 
this strategy is acceptable the software system would undergo continual testing along with 
the ECLSS hardware on the Core Module Integration Facility (CM IF). 


Baseline Criteria -Level B 


• Can be tested on Shuttle 

Comment — This will be very difficult in terms of the technology of ECLSS for Space 
Station. On the other hand it might be of value to design a separate system for the Shuttle 
that tests the ideas in the system. This would, of course, add time and money, to the 
development of the candidate. 

• Actively supports other software/hardware units 

Comment - For the ECLSS systems examined in this report the most important software 
support would come from the "Runtime Object Database" software for the Space Station. 
As this software becomes available it would be necessary to tie into it, since it appears that 
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all sensor reading will be sent to the distributed database systems. In similar ways the full 
ECLSS system would need to tie into the display system and the communications system. 
In the early use of the system these factors would not be as significant since the system 
may be stationed on the ground until its “track record” is demonstrated. 


Evolution Criteria - Level A 

The evolutionary criteria focuses on the possible path from a ground based assistant to an 
embedded system in the Space Station. These criteria in large measure repeat criteria already 
encountered. 

• Low to medium technical difficulty 

Comment — As above, a scale is needed. 

• High payoff 

Comment — As above, a formula is needed. 

• High user demand 

Comment — This will depend on the reaction of users to the initial system, and suggests a 
continuing role for users in the development and evolution of the system. 

• Strong attention to integration of multiple systems 

Comment — Assuming that the attention to non-ES systems has already been determined, 
this criterion seems to focus on the coordination of multiple intelligent systems. This is important 
as the technology is used at various levels. In some sense this should be a general criterion rather 
than an evolutionary criterion since for some of the ECLSS candidates it will be important for them 
to cooperate in some fashion. 
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3.4 Recommendations For Candidate Sites For Advanced Automation 

As indicated earlier in this report there are two ways in which candidates can be appraised. 
From the proposer’s point of view the Slagel and Wick scheme seems appropriate, while from the 
sponsor’s point of view the criterial scheme of the SSAAReport seems appropriate. In either case, 
however, we will not be able to conduct a complete appraisal of the candidate sites that we will 
propose. We will focus on those issues most closely related to the technological and task aspects of 
the candidate proposal and appraisal process. To this end, the section will be divided into several 
subsections. The first section will address the issue of isolating the relevant criteria, the second will 
examine potential candidate sites within the general framework of the previous parts of this report 
that focused on the path to CHKSTA in the P0TH20 unit of WRM, and the final section will 
present our reasoned recommendations. 


3.4.1 Criteria 

In the Slagel and Wick scheme, there are three sorts of questions. Questions about users 
and management are clearly beyond the scope of this report. To address these questions, the 
potential managers and users must be interviewed, and this is not possible given the scope of the 
task. A second group of questions concerns the experts themselves. This would require the 
identifying and interviewing the experts, and, again, this is beyond the scope of this project. 
Although we recognize the importance of these groups of questions there is reason to claim that 
there is a primacy to the questions concerning the task. The questions in this group will be the 
focus of our analyses and recommendations. 

As noted earlier, the SSAA scheme adopts the point of view of the sponsor of the system 
and uses a criterial approach. Although the scheme uses a division into general, baseline, and 
evolutionary criteria subdivided into A, B and C levels, it is possible to interpret the criteria in 
terms of their user and management, expert, and task components. We will focus on the general 
criteria that most clearly correspond to the intent of the task grouping of Slagel and Wick. 

The issues, phrased as questions, can be grouped into three categories. Task specific issues 
are those issues that are directed to the domain that is to be automated. These issues are subdivided 
into supporting and rebutting factors. The supporting factors are those that favor the use of an 
automated knowledge technology, while the rebutting factors provide reasons for not adopting 
such technology. The evaluation issues are directed to the ways in which the advanced automation 
product can be appraised. The implementation issues are directed to those factors that the product 
must address when implemented. 
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The fourteen items, listed below, provide a list of considerations that is both extensive 
enough to address a variety of core concerns and compact enough to be readily applied. Implicit in 
this group of items is the primacy of the task. This primacy is reasonable since the other two 
groupings are dependent upon it. If the task is not a reasonable candidate in terms of these 
considerations, then even if the concerns of managers, users, and experts are supportive of the 
candidate project, it would not be successful since it is not the kind of task that could be 
successfully automated with either today’s resources or the resources that might be expected in the 
near future. This is not to say that the projects that would be more reflective of the concerns of 
managers, users, and experts ought not to be attempted. Many of them should. However, these 
projects would require more extended research, and would not be directly applicable to the context 
of the ECLSS within Space Station Freedom. 


lyes 

Item 

Question 

Reference 

Task specific 
Supporting factors 

1 

Is the task knowledge intensive? Can design 
knowledge be captured and used? 

S&W T2; SS AA General 
level B 

2 

Is the task heuristic in nature? Can a model 
based reasoning approach be used? 

S&WT3; SSAA General 
level B 

3 

Does the task involve subjective factors? 

S&WT17 

4 

Is the task easy, but not too easy? Does the 
task exhibit bounded technical complexity? 

S&W T10; SSAA General 
level A 

5 

Was the task previously identified as a 
problem area? Would the software automate 
what people like to do least; the routine; the 
day-to-day? 

S&W Til; SSAA General 
level A 

Task specific 
Rebutting factors 

6 

Is the task natural language easy? 

S&WT1 

7 

Does the task require little common sense? 

S&W T6 ! 

8 

Can the task be done without optimal results? 

S&WT7 

Evaluation issues 

9 

Are test cases available? Can the success of 
the application be evaluated qualitatively and 
quantitatively? 

S&W T4; SSAA General 
level A 

10 

Can the system undergo incremental growth? 

S&WT5; SSAA General 
level A 

1 1 

Is the task similar to previous KB efforts? 

S&WT14 

12 

Is the task performed at many locations? Is 
there a potential horizontal generality for the 
application? 

S&WT15; SSAA General 
level A 

Implementation issues 

13 

Are solutions explainable and interactive? 

S&WT12 

14 

Does the task lack real-time demands? Can 
the application be firewalled to prevent 
harm? 

S&W T 13; SSAA General 
level A 
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3.4.2 Potential sites 


In the previous discussions of the criteria for the appraisal of candidates, three types of 
candidates were examined. 


lyes 

Description 

Example 

Type 1 

Coordination / Diagnosis / Action for multiple 
intermediary units 

ECLSERR 

Type 2 

Coordination / Diagnosis / Action for non- 
intermediary units 

POTH2G 

Type 3 

Pattern analysis of data 

QUALITY 


These three types will furnish a point of departure for considering candidate systems. 

Type 1 candidates are distinguished by their communication and integration functions. A 
Type 1 candidate absorbs information and knowledge that has to some degree already been 
processed by a lower level system. The obvious sites for this type of automation are at the level of 
the ECLSS support software (ECLSSMGR). However, not all of the components are equally good 
sites. 

ACTIVATE, although a central element of the the ECLSS support software, would not 
appear to be good site. The most direct reason is that the function of ACTIVATE does not seem to 
be one that is amenable to heuristic reasoning. Rather ACTIVATE would seem to function as a 
bureaucratic communications agent. It activates different subcomponents, but does not itself make 
decisions on what should or should not be activated. This seems apparent since both CMD and 
INHIBIT perform operations that would require the decision making (verification, validation and 
inhibition). Further in the crucial area of Fault Detection, Isolation and Recovery (FDIR), it is the 
ECLSSERR subcomponent that both receives failure data and reports critical errors to HABOMA. 

In its present form, ECLSSPER would also not appear to be a good site for artificial 
intelligence based advanced automation. While a good case might be made for the use of such 
techniques in the analysis and interpretation of performance and trend data, the function of this unit 
would seem to be the mathematical analysis of status data and the reporting of short-term trend data 
to HABOMA. In this sense ECLSSPER acts as a computational engine, and not heuristic or 
knowledge intensive engine. Further, the operation of ECLSSPER should be such that subjective 
factors are not relevant but real-time operation is. Both of these count against this site. However, 
should the responsibilities of ECLSSPER be expanded to encompass a more active role in the 
managing of performances, areas for application would be created. 
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The INHIBIT and CMD modules are closely linked. While the tasks that these systems 
perform might be knowledge intensive and might require heuristic reasoning, it is not transparently 
clear that this is so. It might be the case the functions of these units are essentially database and 
interpreter functions. INHIBIT, if so requested, consults the database of inhibited functions and 
sends its results on to CMD. CMD might check to see that the requests and commands coming into 
ECLSS are consistent and syntactically correct. In this sense, CMD acts as an interpreter and not as 
a knowledge intensive decision aid. Alternatively, the two units might act on rules or on past cases 
to make decisions about what functions should be inhibited and which should be allowed. 
Currently, there is not sufficient information to decide which of these options is more likely to be 
the case. Thus, until there is more specific information on these components, they would not 
appear to be good candidates since their functionality might be accomplished with more traditional 
techniques. 

Of the remaining sites one, ECLSSERR, is a classical application of AI advanced 
automation, and the other, DISPLAY, is somewhat novel. The Fault Detection Isolation and 
Recovery (FDIR) tasks of ECLSSERR are essential a combination of a diagnosis task and a 
configuration task. Each of these is a task at which knowledge based systems have proven 
successful in the past. They are knowledge intensive, heuristic, and bounded. They express the 
subjectivity of experts and are not natural language intensive. Although the development of such a 
system might prove to be complex and require a variety of strategies to be used, an advanced 
automation system might prove valuable. Further, given the fact that such systems can be tested 
against test cases based on data acquired during the design and testing phases of both hardware and 
software development, ECLSSERR would seem to be an ideal candidate. DISPLAY, although not 
as clearly an ideal candidate, would also seem to be a good candidate, if it is noted that the data that 
is to be displayed to the user can be enhanced by applying knowledge about human computer 
interaction and heuristics about the relation of data to be displayed. While the overall interaction of 
the display system with the user may create natural language problems, the actual display of the 
data ought not. On this basis the DISPLAY component of the ECLSS software support system 
would also seem to be a good candidate. 

Thus, at the level of the ECLSS software support, the two best candidates are ECLSSERR 
and DISPLAY. 

Dropping to a lower level in the ECLSS, the WRM software presents a more expanded 
selection of candidates. In part, this is due to the fact that types of subsystems present inside of the 
WRM are Type 2 systems. Since the domains of the WRM subsystems are more clearly defined, 
they have been the primary targets of knowledge based systems. For example, both P0TH20 and 
HYGH20 manage the operations of the relevant software on the basis of data, commands, and 
quality statuses. In a way analogous to that of the ECLSSERR, the tasks which each of these units 
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perform are a combination of diagnosis and configuration. The diagnosis comes in terms of the 
subparts of the system with information about failures being sent to the ECLSERR for further 
analysis. The configuration aspect is represented in terms of the configuration of information rather 
than hardware and software. That is, inside of each subcomponent is a bureaucratic unit that 
attempts to build and send messages to other ECLSS units. Although this bureaucratic unit is not 
as knowledge intensive or heuristic as the unit that identifies failures, it may have some knowledge 
intensive aspects in initiating its requests. However, even if the configuration aspect is minimal, 
the diagnostic aspects of these two units are rather strong and recommend themselves as candidate 
systems. 

The H20QUAL unit is somewhat different. The function of this unit is to make a 
judgement about the quality of the water for both the hygiene and potable systems on the basis of 
data concerning iodine, conductivity, pH, and TOC. In a certain sense, the functions of this unit 
are separated from those of P0TH20 and HYGH20 in terms of the physical and chemical aspects 
of the systems. This will become more apparent in the discussion of the components of P0TH20 
(below). However, the task that H20QUAL performs is essentially diagnostic. It attempts to 
determine the quality of the water. This operation would seem to be both knowledge intensive and 
heuristic. Knowledge about the chemical processes and the limits of acceptability would be 
required to decide whether the quality of the water was satisfactory. This might also require that 
tradeoffs and sacrifices be made at various times, knowing the condition of the system and the 
need for water. It is reasonable to think that there would be functions of URINE that would be 
similar to the functions of the foregoing units. The documentation gave no evidence that this has 
been carefully examined at the present time. 

Thus, at the level of WRM the best candidates are P0TH20, HYGH20, and H20QUAL. 

One level deeper in the ECLSS are subcomponents of POTH20. At this level CHKSTA 
controls the physical operation of the various components of the potable water system. The control 
at this level seems to be neither knowledge intensive nor heuristic. Rather CHKSTA can be 
understood as responding to statuses in set ways by turning equipment on and off. The RECH20, 
PURIFY, STORAGE, and QUALITY units are the ones that make the determination of the 
successful or unsuccessful operation of the physical equipment and send failure data to 
ECLSSERR. While the monitoring of such data can be understood as knowledge intensive 
process, it might also be though of as a pattern recognition problem, a Type 3 application. As such 
these sites might make ideal candidates for beginning to apply neural net techniques. These 
techniques are not directly addressed in terms of the items for evaluating candidate systems. 
However, as the technology of neural nets begins to stabilize it might be possible to include them at 
these locations. Currently, a rule based system could be applied, but might prove too brittle to 
contend with sensor input at this level. Further, it should be noticed that the kinds of tasks that 
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these components of POTH20 perform, are physical in nature. In this sense they may prove to be 
less knowledge intensive than the chemical monitoring by H20QUAL, since they would be less 
susceptible to the vagaries associated with the absorption and removal of various chemicals. Since 
the physical abilities of the units at this level can be well established, and since the tasks are 
essentially repetitive, it might be possible to train and test a neural net on board the Space Station 
itself. Finally, the training of the neural nets, might be used as an opportunity for knowledge 
acquisition. This is an important issue if recent work on the conversion of neural net states to mles 
proves effective. 1 1 7 

Thus, while the units of P0TH20 might profit from the use of knowledge based software, 
they might profit more from a neural net approach. 
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3.4.3 Recommendations 


3.4.3. 1 Type 1 Applications - ECLSSERR 



Question 

Response 

1 

Is the task knowledge intensive? Can design 
knowledge be captured and used? 

The ECLSSERR is a clear case for the application of diagnostic 
reasoning that uses knowledge to make judgments. Since the 
knowledge used would include design knowledge a project at 
this site would be supportive of the desire to capture design 
knowledge. 

2 

Is the task heuristic in nature? Can a model 
based reasoning approach be used? 

As in any diagnostic task, the use of heuristics is pronounced. 
A model or cased base approach could be used, in the attempt to 
find the case with the best fit. This would also encourage the 
development of new tools. 

3 

Does the task involve subjective factors? 

Although subjective may be a misleading term, this task does 
involve the use of expert judgement. 

4 

Is the task easy, but not too easy? Does the 
task exhibit bounded technical complexity? 

The task is bounded yet sufficiently complex to warrant 
automation. 

5 

Was the task previously identified as a 
problem area? Would the software automate 
what people like to do least; the routine; the 
day-to-day? 

FDIR is always a problem area. The use of check sheets or 
manual diagnostic aids a prone to human error. Many cases of 
apparent error could be weeded out by a knowledge based 
system and recovery automated for routine operation. 

6 

Is the task natural language easy? 

Natural language input is not required. 

7 

Does the task require little common sense? 

Common sense is not an issue. 

8 

Can the task be done without optimal results? 

The diagnosis can err on the safe side and be satisficing rather 
than optimal. 

9 

Are test cases available? Can the success of 
the application be evaluated qualitatively and 
quantitatively? 

Test cases can be generated as the hardware is developed. The 
qualitative appraisal of the system would depend on both the 
DISPLAY and user satisfaction 

10 

Can the system undergo incremental growth? 

This may prove difficult. However, some classes of problems 
might be attacked before others. 

11 

Is the task similar to previous KB efforts? 

Yes, there are many diagnostic style systems. 

12 

Is the task performed at many locations? Is 
there a potential horizontal generality for the 
application? 

This is not likely unless other space vehicles or stations are 
built with similar hardware and the domain knowledge is very 
similar. However, see below for additional information. 

13 

Are solutions explainable and interactive? 

Explanations would be desirable and they can be built. The 
operation of the system need not be interactive. 

14 

Does the task lack real-time demands? Can 
the application be firewalled to prevent 
harm? 

Some of the operations of the system are not real time. The 
operations that demand real-time action should be trapped 
before being passed to ECLSSERR. It would seem reasonable 
that a toggle could be incorporated to turn the system off, and 
also allow a human to have the final judgement. 


Comment — ECLSSERR is in many ways an ideal candidate for ES technology. Using an ES at 
this level may centralize many of the diagnostic functions at lower levels and thus remove some 
redundancy from the overall software. Alternatively, redundant lower functions can be kept to add 
an added margin of safety. The kind of task that ECLSSERR performs is one in which ES 
technology has had success. It should be noted that for this application of knowledge based 
systems to be successful, it might well be necessary to build better tools that would support the ES 
paradigm and the use of a blackboard structure. Some sort of generic blackboard through which 
results, and perhaps tasks, could be shared should be investigated. 
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3.4. 3.2 Type 1 Applications - DISPLAY 


Item 

Ouestion 

R<?gp<?ns<? 

1 

Is the task knowledge intensive? Can design 
knowledge be captured and used? 

Although not knowledge intensive in the classical sense, a 
good case can be made that the presentations in display ought 
to reflect knowledge about cognition and computer-human 
interaction. 

2 

Is the task heuristic in nature? Can a model 
based reasoning approach be used? 

Since the unit must deal with a wide variety of information 
heuristics about which information to display when should be 
incorporated. A user model that differs from user to user should 
prove to be very effective. 

3 

Does the task involve subjective factors? 

The user model should reflective individual cognitive styles. 

4 

Is the task easy, but not too easy? Does the 
task exhibit bounded technical complexity? 

The design of what is to be displayed is of bounded 
complexity. 

5 

Was the task previously identified as a 
problem area? Would the software automate 
what people like to do least; the routine; the 
day-to-day? 

Traditionally, displays and interfaces are problems for any 
system 

6 

Is the task natural language easy? 

This would depend on the design 

7 

Does the task require little common sense? 

To the degree that it does this would have to be built in. 

8 

Can the task be done without optimal results? 

Yes, as long as the most important information is clearly and 
promptly displaved. 

9 

Are test cases available? Can the success of 
the application be evaluated qualitatively and 
quantitatively? 

It would be difficult to generate test cases, but the users of the 
system should be able to supply clear qualitative evaluations. 

10 

Can the system undergo incremental growth? 

This would seem to be possible. 

11 

Is the task similar to previous KB efforts? 

Many knowledge based system have had to contend with this 
domain, and good interfaces have been developed. 

12 

Is the task performed at many locations? Is 
there a potential horizontal generality for the 
application? 

This would depend on the number of displays on the Space 
Station and the incorporation of the presentation technology 
in other efforts. 

13 

Are solutions explainable and interactive? 

While there may be little need to explain the operations of the 
unit, there may be a great need to make it very easily 
interactive. 

14 

Does the task lack real-time demands? Can 
the application be firewalled to prevent 
harm? 

Speed is important to any display. There is little need to 
firewall the application since it does not control any 
processes. 


Comment — DISPLAY offers many opportunities for the application of AI techniques. Although 
these are to be considered to be some what novel as compared to the well established ES 
technologies, they represent important sites for advanced automation. Ideally the display, through a 
user model should adjust itself to the user. Different crew members would have different user 
models that would allow the display to construct appropriate text and explanations in a way 
informative to that crew member. This is important if the crew members are reasonably anticipated 
to have different levels of experience with the ECLSS. Further, the display should allow tor both 
hypertext links which would allow the user to follow information in his or her own way, and 
prescribed links that would coerce the user to viewing all of the important information available 
through display. The final element which would be valuable to add to DISPLAY would be an 
intelligent word processor that would precompose any reports that the user may need to construct. 
These precomposed reports could be edited and sent along the way without the user having to 
expend a great deal of effort in a routine operation. 
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3.4.3. 3 Type 2 Applications 


WRM: P0TH20, H2QQUAL, HYGH2Q 


Item 

Question 

Response 

1 

Is the task knowledge intensive? Can design 
knowledge be captured and used? 

Each of the tasks within WRM would seem to have a knowledge 
intensive component, and design knowledge might be an 
important part of the knowledge that the system needs. 

2 

Is the task heuristic in nature? Can a model 
based reasoning approach be used? 

The diagnostic nature of the tasks are heuristic, and case and 
model based reasoning can be applied. 

3 

Does the task involve subjective factors? 

Only in the sense of expert judgement. 

4 

Is the task easy, but not too easy? Does the 
task exhibit bounded technical complexity? 

While the tasks are complex, they are technically well defined. 

5 

Was the task previously identified as a 
problem area? Would the software automate 
what people like to do least; the routine; the 
day-to-day? 

Problems with the new hardware are bound to arise and many of 
the problems when diagnosed might have clear solutions. It 
would be better to use advanced techniques than to overload the 
memory and talent of the crew. 

6 

Is the task natural language easy? 

Natural language is not a factor. 

7 

Does the task require little common sense? 

Common sense does not appear to be an issue. 

8 

Can the task be done without optimal results? 

As in the case of ECLSSERR, satisficing is acceptable. 

9 

Are test cases available? Can the success of 
the application be evaluated qualitatively and 
quantitatively? 

Test cases can be generated as the hardware is developed. The 
success of the system might be measured in terms of the 
number of problems it solves without human interaction. 

10 

Can the system undergo incremental growth? 

Yes, new diagnostic units can be added, and old one’s 
improved. 

11 

Is the task similar to previous KB efforts? 

Yes. 

12 

Is the task performed at many locations? Is 
there a potential horizontal generality for the 
application? 

The same basic techniques can be applied in many of the 
ECLSS subsystem and perhaps in other systems. Since all 
knowledge based systems are domain dependent, the systems 
themselves cannot be transferred. However, the case P0TH20) 
and HYGH20 may be atypical, and these might be unified. 

13 

Are solutions explainable and interactive? 

Explanations can and should be generated when needed. 

14 

Does the task lack real-time demands? Can 
the application be firewalled to prevent 
harm? 

Many of the tasks in the WRM are either not real-time or real- 
time is sufficiently long that no problems are created. The 
system can be firewalled in the manner of ECLSSERR. 


Comment — The units of the WRM are the sort of units on which much of the ES effort of the past 
few years has been expended. In this sense they are ideal candidates. However, it should be 
noticed that in each case careful coordination with ECLSSERR must be established. Whether, the 
diagnostics at the lower level are to be used as filters or checks is important. It should be noted that 
the redundancy provided by having diagnostic ES systems at two different levels may provide for 
an increase in firewall protection, but will also add to the complexity of the systems. At this level 
and using only ES technology much can be done, and it is reasonable to think that there are many 
similar situations within the total ECLSS. However, it should also be noted that these applications 
are highly domain specific. As such it is unlikely that they will exhibit any horizontal generality, 
and to the degree that they do this may argue for a software unification as in the case of 
H20QUAL. Again the tools for implementing an ES at these sites might profit from the availability 
of improved software or hardware that would readily support opportunistic inferencing and the 
object oriented paradigm. 
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3.4.3.4 Type 3 Applications 


P0TH20: RECH2Q, PURIFY, STORAGE, QUALITY 


Item 

Question 

Response 

1 

Is the task knowledge intensive? Can design 
knowledge be captured and used? 

Although the tasks could be considered to be knowledge 
intensive. It might be better to consider them to be pattern 
intensive. 

2 

Is the task heuristic in nature? Can a model 
based reasoning approach be used? 

The task is heuristic to the degree that rules of thumb can be 
used to recognize patterns. 

3 

Does the task involve subjecuve factors? 

Not in essential ways. 

4 

Is the task easy, but not too easy? Does the 
task exhibit bounded technical complexity? 

The task can be done with knowledge based systems, but newer 
technologies might prove to be better. 

5 

Was the task previously identified as a 
problem area? Would the software automate 
what people like to do least; the routine; the 
day-to-day? 

Sensor problems are difficult. There is always a desire to add 
another sensor. It might be possible to use either a knowledge 
based system, and knowledge based system with a simulation, 
or a neural net to provide the needed data and checks on the 
data. 

6 

Is the task natural language easy? 

Natural language is not relevant. 

7 

Does the task require little common sense? 

Common sense is not an issue. 

8 

Can the task be done without optimal results? 

There is a greater demand on optimality for these units. 
However, when gauges become faulty or fail to operate 
advanced systems may provide a partial remedy. 

9 

Are test cases available? Can the success of 
the application be evaluated qualitatively and 
quantitatively? 

Test cases could be developed, and for neural nets these could 
be provided as training cases. 

10 

Can the system undergo incremental growth? 

As new patterns are discovered they could either be explicitly 
added as rules or implicitly added as training instances of a 
neural net. 

11 

Is the task similar to previous KB efforts? 

Expert systems have been added to sensors and programmable 
controllers. However, this is still a rather new area, especially 
the neural net technology. 

12 

Is the task performed at many locations? Is 
there a potential horizontal generality for the 
application? 

There is great potential in the development of a system that 
allows for a fall back position when sensors malfunction. If 
such systems proved their worth they could exhibit horizontal 
generality. 

13 

Are solutions explainable and interactive? 

While interaction is not a problem the explainability of the 
results of the system might be. The explanation of pattern 
recognition is difficult. 

14 

Does the task lack real-time demands? Can 
the application be firewalled to prevent 
harm? 

Real time is needed in many of these cases. If there arc not too 
many rules, or if the neural net is fast enough this would not be 
a problem. It would be difficult, but not impossible, to firewall 
a system at this low level. 


Comment — The application of ES technology at this level may prove useful. However, this level 
would also seem to be an ideal site for using neural net technologies. Recent advances in this 
software technique have generated optimism that not only will neural nets prove to be good pattern 
recognition tools, but also that they may prove to be good sensor analyzers or even emergency 
sensor replacements. The latter is the case when some sort of voting procedure is used on sensor 
groups. The failure of any given sensor may lead to it being replaced by a neural net. It should also 
be noted that neural nets may prove to be good knowledge acquisition tools at this level, and, 
therefore, improve upon some aspects of the performance of more traditional ES systems by 
improving the knowledge that they use in inferencing. 
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We would recommend that the process of constructing ES systems begin with the Type 2 
cases inside of WRM. These sites are well suited to the use of ES technology and are the most 
familiar to knowledge engineers and those who construct ES systems. 

The next site to be attacked should be DISPLAY. The interaction of the user with the 
system and the need for explanations would strongly support the application of advanced 
techniques in this area. This will be of great importance if the ESs at the WRM level are initially 
placed in an advisory mode. A system that was only able to display data as advice might impose a 
cognitive burden on the user in those cases in which the user was either unsure of the advice or 
believed that a better course of action was possible. Thus, we believe that the DISPLAY unit will 
be intimately connected to the perceived quality success of any ES. 

A third step in the implementation of advanced automation techniques would be to apply 
them to ECLSSERR. This presents several challenges even though the basic functions which the 
ES would perform have been successfully demonstrated in other systems. The most obvious 
challenge is that of coordinating not only the units that lead to the potable water system, but all of 
the other units as well. As an manager the ECLSSERR must be able to focus its attention on those 
parts of the ECLSS system that most need attention. In some cases this may be AR, in others 
WRM. Further, it should be clear that some of the units of ECLSS may require careful 
coordination. This would be the case in the relation of THC to WRM, for example. 

The final phase in our recommendations would be the application of ES and the 
development of neural net technologies at the level of the subcomponents of POTH20 and related 
units. This is perhaps the most risky application, since either the technology has had difficulties 
being successfully applied at this level (ES), or is novel (neural nets). Thus, the applications of 
advanced AI at this stage should be understood as having to begin at an earlier research phase than 
those at the other two steps. 

Finally, we recommend that an effort be put into the development of tools through which 
the various suggested applications could be well implemented. While CLIPS, for example, is Fine 
at what it does, it does not do as much as may be desirable or needed. The development of 
blackboard tools, object oriented tools, and better inference engines will improve the end product. 
Further the development of such tools may make the various applications integrate more effectively 
with the software of the Space Station. For example, in our discussions of how the candidates 
might be integrated into the the Space Stations software, we began to rely on the proposed 
distributed database system to perform many functions. However, this in the end might not prove 
to be practical. Such a database system would become overloaded if many different systems, 
subsystems, subsubsystems, etc each needed to put and get information from the database. This 
sort of argument might support the implementation of blackboards and other techniques to avoid 
the problem. 


45 



Thus our final recommendations are that: 

• The subsystems of WRM are very good candidates for advanced automation 

• The DISPLAY unit of the ECLSS support system is also a very good candidate 

• ECLSSERR, although more complex, is also a good candidate 

• The subsystems of P0TH20 should be investigated as candidates for ES and neural nets 

• The advanced automation tools for these projects should be expanded and improved. 
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4.0 OVERALL SYSTEM DESCRIPTION 


4. 1 Temperature and Humidity Control (THC) 

4.1.1 S ubsystem Description 

The THC performs three functions: 1) cabin air temperature, humidity, and ventilation 
control, 2) cooling of rack-mounted equipment; and 4) refrigerator/freezer provisions.5’88,1 12 
(See Figure 7.) 


4. 1 . 1. 1 Cabin Air Temperature Humidity and Ventilation Control 

The cabin air temperature and humidity are controlled by circulating air through a 
condensing heat exchanger assembly. 88 A mechanical schematic of the cabin temperature and 
humidity control mechanism is shown in Figure 8. Ventilation provides intramodule flow rates for 
air that is circulated via ventilation fans within the habitable environment of the element * These 
areas include the main cabin, crew quarters, exercise facility, personal hygiene facility and 
wardroom. Intermodule air provides for air circulation for the respirable air that is distributed from 
the Habitation (HAB) module or Laboratoyr (LAB) module to the other pressurized elements. 

The atmosphere for the entire station is revitalized from a centralized source. Airborne particulate 
and microbial removal are provided for in this subsystem.^>88 High Efficiency Particulate Air 
(HEPA) and coarse filters are used to remove particulate and microbial contents to acceptable 

levels. ^ ^ 

The humidity control system is composed of three essential elements; the condensor, the 
collector and a separator/pump assembly.The condensor consists of a plate-fin heat exchanger 
with a four pass, cross counterflow coolant loop. The primary challenge in designing this 
subsystem involves gas/fluid separation in the absence of a gravity field. This separation may be 
accomplished on the space station with a "slurper" or rotary separator system. This system has 
several advantages over "elbow separator and scupper " or wick systems flown previously on the 
Space Transportation System (STS). 112 
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Source: NASA. 1989. "Environmental Control and Life Support System Architectural Control Document,"' NASA 
Marshall Space Flight Center, February 15, 1989. 5 


Figure 7. ECLSS Temperature and Humidity Control (THC) Functional Schematic 
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Source: Carter, Charve. ’’Rack and Subsystem Level Schematics, ECLSS Subsystem Groups, and General 
Regenerative ECLSS Flow Diagrams", Boeing Aerospace.^ 


Figure 8. Avionics Cooling Assembly Mechanical Schematic - HAB, LAB 
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4. 1 . 1 .2 Avionics Air Cooling of Equipment 


The air cooling equipment in the THC subsystem also provides air flow to the rack- 
mounted equipment for cooling and fire detection. A fan assembly produces the air flow and the air 
is cooled by a heat exchanger assembly which transfers the heat to the Internal Thermal Control 
System. Avionics air flow is supplied to racks containing power consuming equipment, and to 
storage racks containing combustible material. ^8 A mechanical schematic is shown in Figure 8. 

4.1. 1.3 Thermally Conditioned Storage 

Refrigerators and freezers are controlled by the THC subsystem for the purpose of food 
and drink storage, material and life science storage, and return of perishable items. Options being 
considered include the use of body mounted radiators, a vapor-compression refrigeration cycle, or 
a thermoelectric cooling device.^ The Internal Thermal Control System (ITCS) removes waste 
heat from all internal systems including the ECLSS. The refrigerator/freezer design is a key 
interface that still needs to be resolved between ECLSS and ITCS.88 The issue of liquid verses air 
cooling is also undecided. 
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4.2 Air Revitalization (AR) 


The AR subsystem is responsible for the revitalization of the Space Station Freedom 
atmosphere so as to provide a safe and habitable environment for the crew A70 consists of four 
systems: regenerative CO 2 removal, CO 2 reduction, O 2 generation, and trace contaminant control 
and monitoring. 5,70,88 (See Figure 9). There are several competing technologies for each AR 
subsystem group. Computer models and comparative subsystem testing are being used to evaluate 
their advantages and disadvantages. 49 Oxygen and hydrogen are generated by electrolysis from 
hygiene or potable water. The hydrogen is combined with CO 2 in the CO 2 reduction subsystem to 
produce water which is delivered to the potable water reclamation subsystem. 

Trace contaminants are monitored and removed via the Trace Contaminant Control 
Subsystem (TCCS) by charcoal beds, catalytic oxidizers, and sorbent beds.5>70,88 


4.2.1 CO 2 Removal 

The CO 2 removal unit removes and maintains the control limit of metabolic CO 2 from the 
cabin atmosphere.^ The CO 2 removed is concentrated from the air that has returned from the cabin 
and transferred to the CO 2 reduction subsystem.^ Several technologies are being developed and 
tested for final selection as described below. 


4.2. 1 . 1 4-Bed Molecular Sieve (4-BMS) 

The 4-BMS uses Zeolite 5A sorbent to adsorb CCb from the inlet air stream by trapping the 
molecules in voids in the crystal lattice structure of the Zeolite 5A. 49,103 (S ee Figure 10). This 
adsorption is accomplished due to molecular size, polarity of the molecules, and vapor pressure 
factors. Since Zeolite has a greater affinity for water, the air must be dried upstream of the CO 2 
sorbent bed with a desiccant bed of silica gel and/or Zeolite 13 X. 49 . The sorbents alternately 
adsorb and desorb CO 2 , thus requiring two each of the sorbent and desiccant beds. The desorbed 
gas is stored in an accumulator before sending it to the CO 2 reduction subsystem.! 03 
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Marshall Space Flight Center, February 15, 1989. 5 


Figure 9. ECLSS Atmospheric Revitalization (AR) Functional Schematic 
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Figure 10. 4-Bed Molecular Sieve Schematic* 
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Figure 11. Electrochemical Depolarized Cell (EDC) Schematic* 
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Figure 12. Solid Amine Water Desorbed (SAWD) Schematic* 


Source: Ray Ogle, Tipps, Carrasquillo, and Wieland. 1987. "The Space Station Air Revitalization Subsystem 
Design Concept. S AE 871448. Life Support and Environmental Branch, NASA, Marshall Space Flight 

Center. 
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An independent subsystem test of the 4-BMS was performed at Marshall Space Flight 
Center (MSFC) in May 1987.103 Carbon dioxide was removed from the air feed for 3 hours and 
samples of product concentrated CO 2 were analyzed for carbon dioxide, nitrogen and oxygen. 
Oxygen and nitrogen were found in the samples indicating that the sieve beds adsorbed some 
interstitial air along with carbon dioxide due to some leakage into the subsystem during the test. 
Future testing will incorporate an oxygen sensor in the CO 2 outlet line to monitor purity of 
CO 2. 103 

Advantages of this technology are that it can be operated independently of the other ECLSS 
subsystems, it does not impact cabin humidity, the sorbent materials are chemically stable and odor 
free and do not require regular changeout. 49 Disadvantages are the complexity of the hardware 
and controllers, and the relatively high weight and power requirements. 49 


4.2. 1.2 2-Bed Molecular Sieve (2-BMS) 

A molecular sieve sorbent made of carbon has been developed which adsorbs CO 2 in 
preference to water. Therefore the desiccant beds in the 4-BMS are no longer required to pre-dry 
the air, and only two beds of CO 2 sorbent are needed for continuous, cyclic operation. 49 


4.2. 1.3 Electrochemical Depolarized Cell (EDC) 

This subsystem produced by Life Systems Inc. under contract to NASA utilizes an series 
of electrochemical cells, each made up of two electrodes separated by a porous matrix containing 
an aqueous metal carbonate solution. 49 CO 2 desorbed from the air stream is transformed into 
carbonate and bicarbonate ions which migrate from the cathode to the anode. At the anode the CO 2 
is released from low partial pressure atmospheres into a stream of H 2 and CO 2 suitable for 
reduction processing. (See Figure 1 1). The EDC is fairly light (5 to 10 lbs) and is a net producer of 
power (54 to 71 watts). Since the EDC is the lightest, most compact, and a net power producer, it 
appears to be the most desirable technology. 64 

Advantages of this subsystem are that it has the lowest weight and volume of the 
subsystems being considered, and as of 1987 it was nearest to flight hardware design. 49,64 
Disadvantages are that it requires coupling with an H 2 source which would cause a shutdown 
during supply failure and which during safe haven would require a source of H 2 . Also, the 
presence of H 2 raises safety concerns.49 Future development includes studying a variation which 
can remove and concentrate CO 2 without the use of H 2 49 
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4.2. 1 .4 Solid Amine Water Desorbed (SAWD) 


The SAWD CO 2 concentrator uses a weak base amine ion exchange resin to chemically 
absorb CO 2 from a mixed air stream. The amine combines with water to form a hydrated amine 
which then reacts with CO 2 to form bicarbonate. Steam is injected into the amine to break the 
bicarbonate bonds and the CO 2 is released. Since this process is cyclic, two sorbent beds are 
required.49,9 1 (S ee Figure 12). 

Advantages of this subsystem are that it is near flight hardware design, it has relatively low 
weight and power requirements, and it can operate independent of loop closure. 49 Disadvantages 
include significant impact from the water required for steam generation, impact on cabin humidity 
due to steam discharged, periodic replacement of the amine material, safety concerns of pressurized 
steam, and the relatively complex hardware and controllers.^ 


4.2.2 CO 2 Reduction 

The CO 2 reduction unit utilizing hydrogen, reduces CO 2 to water and other reaction 
byproducts depending on the technology used. ^>49,58,89, 90,97 Several technologies are being 
developed and tested for final selection as described below. 


4.2.2. 1 Sabatier CO 2 Reduction Subsystem 

The Sabatier CO 2 reduction subsystem reacts carbon dioxide and hydrogen over a 
ruthenium on alumina catalyst to produce methane and water in an exothermic reaction. 49, 103 ($ ee 
Figure 13). The product water vapor is condensed and separated from the other exit gases and sent 
to the potable water recovery loop. 49, 103 An independent subsystem test was performed in May 
1987.103 Gas anc i product water samples were collected and chemically analyzed. The reaction 
efficiency based on inlet and outlet gas was calculated to be 99.4%. During metabolic control 
testing in November, 1987, the reactor produced 100% of the water possible from reactant input, 
the separator collected and delivered 86% of this water, the cold trap another 9%, and the 
remaining 5% was lost with the vented methane. Overall the Sabatier successfully performed at 
near 100% efficiency .91 

Advantages of the Sabatier subsystem are its high level of development, its greater 
reliability , its not requiring cartridge changeouts, possibly not requiring storage of products, and 
its easy handling of increased loads. 49 Disadvantages include the potential need for 
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Source: Adapted from "Water Monitoring Requirements, Current Requirements, and Subsystem Schematics"^ 5 ; and 
Ray, Ogle, Tipps, Carrasquillo, and Wieland, "The Space Station Air Revitalization Subsystem Design 
Concept," SAE 871448, Life Support & Environmental Branch, NASA, Marshall Space Flight Center^. 

Figure 13. Sabatier CO 2 Reduction System Schematics 
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methane storage, and the loss of CO 2 due to an incomplete reaction. 49 Unless the methane 
produced is "recycled " by use as propellant or in fuel cells the net loss of H 2 for the station system 
may represent a significant resupply penalty. 89 Many concerns have been expressed for the 
possible negative effects of vented methane on astronomy and scientific experiments. 

4.2.2. 2 Bosch CO 2 Reduction Subsystem 

The Bosch process is a technique for the reduction of the carbon dioxide removed from the 
Space Station Freedom atmosphere and the subsequent water formation for oxygen recovery. (See 
Figure 14). The Bosch process occurs from 426 to 726°C in the presence of a catalyst. One mole 
of carbon dioxide combines with two moles of hydrogen gas to produce one mole of carbon and 
two moles of water vapor in an exothermic reaction. 49,97 Approximately 10% of the CO 2 is 
reacted in each pass requiring a recirculating loop to increase the conversion efficiencies. 49,97 
Unreacted CO 2 and H 2 , and gaseous byproducts CO and CH 4 are continuously recycled to the 
inlet, while product water is condensed and separated. 49 A cold seal reactor design is used which 
eliminates the tremendous heat loss at the closure interface and eliminates the need for a vacuum 
interface. The entire process is contained within a ruggedized disposable carbon cartridge. 9 7 
There is a recuperative heat exchanger that preheats the recycle loop gases with hot gases exiting 
the condenser, thus maximizing thermal efficiency. The heat exchanger has a spiral coil design 
which eliminates inactive areas. 97 

One of the hazards of the Bosch design was the cartridge removal. To avoid potential safety 
hazards an automatic N 2 purging of the carbon cartridge is done under a vacuum both before and 
after cartridge replacement.97 Other components of the Bosch subsystem include a recycle loop 
compressor, recycle gas composition controller, vales, regulators, condensing heat exchanger, and 
gas/water separator. The compressor in the recycle loop controls the overall Bosch CO 2 reduction 
rate by controlling the recycle flow rate. The stoichiometry is controlled by measuring the 
volumetric H 2 concentration in the recycle loop. A zero-gravity compatible gas/water separator is 
used to remove the product water condensed by a heat exchanger in the recycle loop. 

The Bosch system can be automatically controlled by a control monitor which incorporated 
microcomputer software. Computer control is used to adjust the configuration of the process when 
switching between operating modes, to control operating mode routines, for fault detection, fault 
isolation, and fault prediction, and for built-in diagnostics for subsystem verification .97 
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Figure 14. Bosch C02 Reduction Subsystem Schematic 
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The Bosch II prototype is currently in operation at the NASA MFSC Test Chamber. The 
Bosch process is reaching a level of technological maturity demonstrating its viability for 
application aboard Space Station Freedom .97 

This process is promising because no on-board gaseous storage or overboard venting is 
required, and there is a potential for 100% efficient CO 2 recovery .97 Aspects that still need to be 
addressed are optimization of power consumption, expendable weight, crew safety, and 
compatibility with Space Station Freedom interfaces. 

Advantages of the Bosch subsystem are the high level of development, complete reduction 
of CO 2 , compatible in zero-gravity environments, and its possible integration with the propulsion 
system by supplying excess H 2 ■ Disadvantages include the need to change out the cartridges 
and the potential risk of contamination from the low density carbon product, the longer startup 
time, and the higher weight and power requirements.49,89 


4.2. 2. 3 Advanced Carbon Reactor System (ACRS) 

The ACRS is a combination of the Sabatier and the Carbon Formation Reactor (CFR). As 
in the Sabatier, carbon dioxide and hydrogen react to form methane and hydrogen gas. The 
methane is converted to carbon and hydrogen gas, the hydrogen is recycled, and the carbon formed 
is deposited inside a quartz fiber-packed reactor. Two CFR's are required for continuous 
operation. 49 (See Figure 15). 

Advantages of the ACRS are that its dense carbon in the cartridges would be a lower 
contamination risk and a much less expendable volume than with those of the Bosch system, and 
the ACRS provides full reduction of CO 2 and excess hydrogen for potential propulsion 
integration. 49 Disadvantages of the ACRS are that it is the least mature subsystem requiring 
extensive development; it has the highest operating temperature, weight, and power requirement; 
and it requires cartridge changeout. 


4.2.3 O 2 Generation 

The O 2 Generation System generates oxygen for metabolism, leakage, and airlock 
replacement; and generates hydrogen for use in the CO 2 reduction unit by electrolyzing water. ^ 
Several technologies are being developed and tested for final selection as described below. 
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Figure 15. Advanced Carbon Reactor System (ACRS) Schematic 
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4.2.3. 1 KOH Static Feed Electrolyzer (SFE) 


The function of the SFE is to generate 02 for metabolic consumption, leakage makeup, and 
O 2 and H 2 consumption by other ECLSS systems.95 Water is electrolyzed in 12 cells consisting 
of a water feed cavity, and a cell matrix cavity that initially have equal concentrations of 
electrolyte.^’ *03 (See Figure 16). The water and gas are separated by membranes, and the gases 
are separated by Potassium Hydroxide (KOH) electrolyte. 103 As electrical power is supplied to the 
electrodes, water in the cell matrix is electrolyzed creating a concentration gradient between the 
electrolyte in the water feed cavity and the electrolyte in the cell matrix. The water vapor diffuses 
from the water feed matrix into the cell matrix due to this gradient. Waste heat is removed by a 
liquid coolant controlled by a Coolant Control Assembly. A Pressure Controller maintains 
pressures during start-ups and shutdowns. The N 2 purge is not used during normal 
operation. 95 Finally, there is a Fluid Control Assembly which controls and monitors the SFE 
water tank fill, water feed and purge gas flows. The subsystem is controlled by micro-processor 
or computer-based instrumentation which provides for parameter control, automatic mode and 
mode transition control, automatic shutdown for self-protection, fault diagnostic functions and 
interfacing with data acquisition systems. 95 

Advantages of the SFE are that its simple replaceable unit design is easily maintained; its 
efficiency approaches 100%; its power, weight, and volume requirements are low; and the water 
content of the product gases are lower than it would be with a solid electrolyte.^ Disadvantages 
are that the liquid electrolyte is a potential source of caustic leakage, and the cell matrix cannot 
withstand high differential pressures requiring careful control of cell cavity pressure. 49 


4.2.3. 2 Solid Polymer Electrolyte (SPE) 

The SPE separates water from the hydrogen compartment by a vapor permeable membrane. 
When power is supplied, the water is converted to O 2 at the anode. A water concentration gradient 
is set up within the electrodes and the solid polymer electrolyte.49 Solid Polymer Electrolyte 
(SPE) O 2 generation by water electrolysis became practical in the late sixties with the introduction 
of fluorocarbon ion exchange membranes. Developed by Hamilton Standard under contract to 
NASA, the SPE vapor feed electrolizer is capable of supplying 0.06 lbs./hr. of O 2 at 3000 psi. A 
design used in nuclear submarines was modified to eliminate rotating equipment, the pre- 
deionizer, and associated maintenance. The design uses the energy in the high pressure hydrogen 
produced within the electrolyzer to pressurize the input process water 3000 psi. without the use of 
a mechanical pump. 60 (See Figure 17). 
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Source: NASA. 1989. "Environmental Control and Life Support System Architectural Control Document," NASA 
Marshall Space Flight Center, February 15, 1989.^ 


Figure 17. Solid Polymer Electrolyte (SPE) Schematic 
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Advantages of the SPE are that the acid electrolyte is immobilized in the membrane, it 
contains no hazardous liquids, and its membrane exhibits high strength which can withstand high 
differential pressures. Disadvantages include its lower efficiency than the alkaline subsystems, and 
the higher vapor content of its product gases .49 


4.2.4 Trace Contaminant Control Subsystem (TCCS) 

The TCCS will remove trace contaminants and odors from the cabin atmosphere. 5 Several 
options currently in design include a fixed bed with charcoal and sorbents for removal of specific 
contaminants, a high temperature catalytic oxidizer with pre- and post-sorbent beds, and a low 
temperature carbon monoxide oxidizer. 49 (See Figure 18). 

4.2.4. 1 High Temperature Catalytic Oxidation 

1 . Expendable Adsorbers 

a) Carbon Adsorbers 

b) Acid Gas Adsorption 

2. Regenerative Adsorbers 

a) Carbon Adsorption 

b) Acid Gas Adsorption 

4.2.4.2 Sequential Catalytic Oxidation 

1. Expendable Adsorbers 

a) Carbon Adsorbers 

b) Acid Gas Adsorption 

2. Regenerative Adsorbers 

a) Carbon Adsorption 

b) Acid Gas Adsorption 
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Source: Ray Ogle, Tipps, Carrasquillo, and Wieland. 1987. "The Space Station Air Revitalization Subsystem 

Design Concept. S AE 871448. Life Support and Environmental Branch, NASA, Marshall Space Flight 

Center ^9 


Figure 18 . Trace Contaminant Control Subsystem (TCCS) Potential Design 
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4.2.5 Trace Contaminate Monitor 


Contamination monitoring equipment monitors trace contaminants that are present as vapor 
or gases and total particulate levels in the cabin atmosphere.5>59, 77,82 

We have been unable to identify a particular system baselined for station ECLSS use. 
There are several relatively mature technologies available and development in this area may be low 
priority. The CAMS I system (Central Atmospheric Monitoring System) was developed for the 
space program and is currently used on US submarines. This instrument consists of a mass 
spectrometer and nondispersive infrared analyzer (FTIR) which simultaneously monitors eight 
gaseous contaminants. CAMS II is in final development and will monitor 12 preselected 
contaminants, including refrigerants and hydrocarbons, using a scanning mass spectrometer in 
conjunction with a photoionization detector. A similar system is likely to be adapted to station 
use.** 2 


4.2.6 Particulate Control 

Cleanliness requirements for the Space Station Freedom require that the 
particulate/microbial contamination load be controlled. The following are descriptions ot some 
technique being considered for this control. 


4.2.6. 1 High Efficiency Particulate Air Filters (HEPA) 

HEPA's are 99.97% efficient in filtering particles 0.3 micrometers or larger in size. Coarse 
filters are used prior to the HEPA's to reduce clogging. Advantages of the HEPA filters are that 
they are the only method capable of meeting the Space Station Freedom cleanliness requirements as 
a stand alone method, and that they filter in the sub-micrometer size ranged Disadvantages are 
that they have a relatively high energy requirement and their efficiency depends on appropriate air 
flow being supplied.^ 
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4 . 2.62 Negative Ionization Electrostatic Precipitation 


Negative-ionization electrostatic precipitation has been used in nuclear submarine closed 
environments to remove particulates.^ This method is highly effective for particles in the 0. 1 to 
10 micrometer range, has a relatively low pressure drop, and has the potential for reuse. 
Disadvantages are that it requires relatively high energy inputs, and uses high voltages which can 
possibly produce ozone and electromagnetic interference.^ 


4. 3. 6.3 Ultraviolet Radiation 

Ultraviolet radiation is effective in killing airborne microbes including yeasts, molds, 
bacteria, rickettsiae, mycoplasma, and viruses.^ Disadvantages of this method are the potential of 
UV radiation exposure to the crew, the possibility of ozone production, and mercury release in the 
event of lamp breakage.^ 
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4.3 Atmospheric Control and Supply (ACS) 


The ACS subsystem is responsible for the regulation and control of total pressure, oxygen 
partial pressure, and gas composition for all pressurized elements of the Space Station 
Freedom.5/70’88 j^e acs provides an internal environment to support and maintain crew 
comfort, convenience, health and well being by keeping the respirable atmosphere within certain 
requirements.^ It's functions also include accommodation of: atmospheric leakage of each module 
at a maximum of 0.23 KG/day with an overall station maximum of 2.27 KG/day, experiment vent, 
airlock losses, and pressure vent and relief capability. This subsystem contains the oxygen and 
nitrogen storage and resupply tanks for atmospheric makeup, repressurization, hyperbaric chamber 
operations, and O 2 /N 2 distribution equipment throughout the pressurized elements. 88 See 

Figure 19 for the ACS functional schematic. 


4.3.1 O 2 /N 2 Pressure Control 

O 2 /N 2 pressure control regulates the composition of the atmosphere for the modules, 
resource nodes, airlock and hyperbaric airlock atmosphere. It also maintains the total pressure. 
The atmospheric pressure control maintains the internal pressure at 14.7 plus or minus 0.2 psia lor 
the station and for any pressurized element independent of the rest of the station. If any single 
element loses its atmosphere unexpectedly, emergency repressurization is invoked to restore the 
station to operational status. During hatch opening and closing, pressure equalization is provided 
by equalization valves. Airlocks are operated from 14.7 to 0 to 14.7 psia during exit and entry 
from space. Pressurization for the hyperbaric chamber is used to treat bends or air embolism and 
requires rapid increase in the hyperbaric chamber pressure.5>56 

4.3.2 Vent and Relief 

Vent and relief hardware provides for the capability to avoid over or under pressure 
conditions, depressurize habitable volumes, equalize pressures between modules, and permit the 
transportation of pressurized volumes from the ground to orbit. ^ A schematic of the vent and reliet 
assembly and pressure equalization is shown in Figure 20. 
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EXTERNAL EXTERNAL 


Source: NASA. 1989. "Environmental Control and Life Support System Architectural Control Document," NASA 
Marshall Space Flight Center, February 15, 1989.^ 


Figure 19. ECLSS Atmosphere Control and Supply (ACS) Functional Schematic 
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Source: Carter, Charve. "Rack and Subsystem Level Schematics, ECLSS Subsystem Groups, and General 
Regenerative ECLSS Flow Diagrams", Boeing Aerospace.-^ 

Figure 20. Vent and Relief Assembly and Pressure Equalization Schematic 
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4.3.3 O 2 /N 2 Storage 


O 2 /N 2 storage tanks provide oxygen and nitrogen for the repressurization of a single 
pressurized element, plus one operating cycle of the hyperbaric chamber. N 2 storage tanks 
provide nitrogen atmosphere makeup.^ 


4.3.4 O 2 /N 2 Distribution 

O 2 /N 2 distribution plumbing consists of internal/external lines, valves and quick 
disconnects to facilitate the integration of subsystem components.^ A schematic of the nitrogen 
distribution system is shown in Figure 21. 


4.3.5 Atmosphere Composition Monitoring 

In addition to trace contaminant monitoring functions mentioned in earlier sections on the 
ARS, a O 2 partial pressure sensor will provide O 2 partial pressure information for makeup gas 
balancing. The Zirconia sensor block has two electrode systems, one across a ambient gas filled 
chamber and one with PdO paste. Galvanometric and Voltametric measurements across these 
junctions provide for self correction/calibration of the sensor. 76 

An improved pressure decay sensor and pressure balanced latching valve are under 
development to provide improved automatic control of atmosphere composition. 1 12 
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Source: Carter, Charve. "Rack and Subsystem Level Schematics, ECLSS Subsystem Groups, and General 
Regenerative ECLSS Flow Diagrams", Boeing Aerospace.^ 


Figure 21. ECLSS Nitrogen Distribution Schematic 
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4.4 Fire Detection and Suppression (FDS) 


The FDS subsystem comprises hardware that detects and suppresses fires within the pressurized 
elements of the Space Station Freedom.5>88 Sensors are being tested that can detect fires in the 
four stages of combustion: incipient, smoldering, flame and heat. (See Figure 22.) Ionization 
detectors, infrared/ultraviolet sensors, and thermal sensors are being considered. Fire suppression 
consists of the tanks and distribution system that supply the fire suppressant to equipment racks 
and standoffs, and portable extinguishers for manual fire suppression. 5 Fires are first located, their 
magnitude determined, and then they are isolated. Isolation is first performed at the rack level by 
cutting off airflow through the rack, releasing suppressant into the rack, and removing power from 
the rack. Second, if needed, the intermodule airflow is shut off, hatches are closed, and the 
module atmosphere is vented to spaced Either CO 2 or Halon 1301 will be used as the primary fire 
suppressant. The Halon 1301 is better for flammable liquid and electrical fires. CO 2 however 
provides better cleanup in a closed environment situation. 88 

A Quartz Crystal Microbalance (QCM) sensor was originally proposed for STS use 1 13 but 
stability and calibration problems forced development of an alternative. An active ionization 
detector using Am 241 was produced to detect submicron pyrolitic matter. This fire sensor 
technology has proven stable and reliable for STS use and it is anticipated that a similar design will 
be used for the station. 
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NOTE (1) Air flow shall cease upon fire detection 
and release of fire suppressant. 


Source: NASA. 1989. "Environmental Control and Life Support System Architectural Control Document," NASA 
Marshall Space Flight Center, February 15, 1989. 5 


Figure 22. ECLSS Fire Detection and Suppression (FDS) Functional Schematic 
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4.5 Waste Management (WM) 


The WM subsystem processes and stores fecal matter and other associated wastes. 88 There 
are three main subsystems; urine collection, fecal collection and processing, and return waste 
storage. 107 

The STS waste management has required some redesign work 11 and recent improvements 
have generally been successful in handling this waste while meeting crew hygiene and asthetics 
requirements. Since compacted fecal waste will be returned from the station, STS technology may 
be directly applicable for this subsystem. No information was available on new development work 
in progress. 
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4.6 Water Recovery and Management (WRM) 


The main function of WRM is to provide a safe reliable supply ot water to meet Space 
Station Freedom needs, while minimizing water-related resource requirements. 44 The WRM 
subsystem includes processors that reclaim water from various waste water sources (both within 
the ECLSS as well as other Space Station Freedom systems such as Man Systems, health 
maintenance, propulsion, and transportation systems), and distributes the reclaimed water to the 
U.S. modules, nodes, airlock, hyperbaric chamber, and logistics module. It also monitors the 
water distribution system for microbial and chemical contamination, thermally conditions water, 
and stores water. Two grades of water are produced: hygiene water and potable water.^8,44 (See 
Figure 23.) 


4.6. 1 Potable Water System 

The Potable Water system is functionally centralized, with two units located in each ot the 
U.S. modules. Four units are needed to satisfy the safe haven safety-critical function. This means 
that if there were two non-repairable failures and/or a loss of either of the U.S. modules, then they 
would have to meet a fail-operational/fail-safe/restorable criteria.5>44,88 Potable water is the grade 
of water that is used for crew ingestion, oral hygiene, food preparation, Health Maintenance 
Facility uses, and portable emergency provision. 5 It is produced by the reclamation of humidity 
condensate collected from the cabin atmosphere and product water from C02 reduction. 44, 8 8 
Potable product water is checked for safe water quality parameters and stored prior to use. This 
system is described in detail in Section V. 


4.6.2 Hygiene Water System 

Hygiene water is used for non-ingestive crew activities such as handwashing, showers, 
dishwashing, laundry, urinal flushing, and O 2 generation.^ The Hygiene water system is also 
functionally centralized, but only requires two units since it is not considered a safety critical 
system. One unit is located in each U.S. module. 44 Hygiene water is produced by reclaiming 
water from the Man Systems such as urine, shower, handwashing, dishwashing, and clothes 
washing. 88 The system hardware includes pre/post treatment, processing, and product quality 
monitoring which is described in later sections.^ 
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Figure 23. ECLSS Water Recovery and Management (WRM) Functional Schematic 
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Product water from the hygiene reclamation system in checked for water quality parameters and 
stored. Product hygiene water is used in the Man Systems as well as in oxygen generation in the 
ARS subsystem, and for urinal flush water in the WM subsystem. 


4.6.3 Urine Water Recovery 

The urine reclamation is accomplished in a separate process from the other reclamation 
processes. 44 It provides for the extraction of water from urine/flush water and includes the 
hardware for pretreatment, processing, product quality monitoring, and storage of concentrated 
brine. ^ Specific competing technologies are described in later section 4.6.5. It is necessary to 
pretreat urine prior to distillation to fix free ammonia, inhibit microbial growth, control odor, and 
reduce foaming. Several oxidizing and non-oxidizing pretreatments are being considered; including 
oxone, CuS04, hydrogen peroxide, and several proprietary surfactants. 52 


4.6.4 Water Quality Monitor 

Boeing produced a schematic for a Water Quality Monitor "ADP EC-3" in May 1988. 
(See Figure 24). It includes streams from the process line going through strainers, pH and TOC 
meters, and finally spectrophotometric analysis. 

The current technology under evaluation for Total Organic Carbon (TOC) analysis is based 
upon ultra-violet absorption. It can handle extremely low levels (0.02ppm) on a continuous basis, 
and the sample is totally unchanged after exiting the unit.^ 4 Previous technologies for measuring 
TOC involved the use of a batch process using expendable and potentially dangerous chemical 
reagents, relied to some degree on gravity separation, had longer periods of response, and were 
not as sensitive to some of the major organic compounds common to space station reclamation 
water. ^ 4 

Astro was able to show that UV absorbance readings correlate reasonably well (+/- 30%) 
with conventional oxidation/infrared detection measurements when applied to "a variety of actual 
treated (recycled) water samples." However, many organic compounds, some toxic, do not absorb 
in the UV region. Although only 2 ppm of KHP (potassium hydrogen phthalate) is necessary to 
get a full scale reading, it requires over 60,000 ppm of ethanol to produce the same 100% 
absorbance reading. The limitations of this device are obvious.^ 4 
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Figure 24. ADP EC-3 Water Quality Monitor Schematic 
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4.6.5 Reclamation Technologies 


There are four phase change technologies and two non-phase change processes being 
considered for use in the WRM. The phase change technologies are distillation-type operations 
which separate water from waste water using evaporation, and require significantly higher energy 
for operation. The non-phase change technologies utilize physical and chemical processes such as 

A A 

particulate filtration, adsorption, ion exchange, and/or membrane technologies to separate water. 

The phase change technologies include: Air Evaporation Subsystem (AES), the 
Thermoelectric Integrated Membrane Evaporation Subsystem (TIMES), the Vapor Compression 
Distillation Subsystem (VCDS), and Vapor Phase Catalytic Ammonia Removal (VPCAR). The 
two non-phase change technologies are Multifiltration (MF) and Reverse Osmosis (RO). 


4.6.5. 1 Air Evaporation Subsystem (AES) 

A wick feed air evaporator is presented as an alternative to the TIMES & Vapor 
Compression Distillation (VCD) subsystem. A preprototype unit was produced by Airesearch 
Manufacturing Corp. in conjunction with Umpqua Research under MSFC contract. (See Figure 
25). The system is capable of 100% water recovery from urine, wash water, RO brine, etc. It 
utilizes a circulating air stream, air heater, wick evaporator, and condensing heat exchanger tor 
reclaiming process water from heavily contaminated feed streams. The AES uses a felt wick 
saturated with waste water as the vapor/liquid interface. Wicks load up with solids until capillary 
action is severely affected. The wick pads are then replaced, at an approximate rate of one wick 
package unit per 15 days, and spent pads with the solid contaminants are dried and placed in waste 
management for return to earth. 69 Water in the humidified air leaving the wick is condensed, and 
passed through sorbents and resins to remove volatile contaminants. ^4 The system is light, 
rugged, and requires little power. Unfortunately wick pads must be delivered and returned trom 
orbit indefinitely. 69 


4. 6. 5. 2 TIMES 

The TIMES separates water from wastewater or urine by means of a vacuum distillation 
process with hollow fiber fluorocarbon based cation exchange membranes. 44, ,9 1,1 03 (See 
Figure 26). Pretreated urine enters the recycle loop where it is heated to 135°F on the hot side of a 
thermoelectric heat pump. Part of the flow evaporates on the low pressure side of the hollow-fiber 
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Source: Morasko, C.A. Torrance, and Bagdigian. 1986. "Air Evaporation Closed Cycle Water Recovery Technology 
- Advanced Energy Saving Designs." SAE 860985. 69 


Figure 25. Air Evaporation System Schematic 
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Figure 26. Thermoelectric Integrated Evaporation Subsystem (TIMES) Schematic 
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membranes and flows to the cooler, condensing side of the thermoelectrics. Water vapor that 
collects on the exterior fiber surface is condensed and delivered to the post-treatment section or to 
the hygiene processing loop.^l Latent heat is recirculated to the waste water. Unevaporated 
concentrated waste water is sent to brine storage for return to earth. 44 

In the 1987 independent subsystem tests of the TIMES at MSFC it was found from the 
chemical and microbial analyses that the halogenated hydrocarbons chloroform and trichloroethane 
were two compounds which were found to exceed the lower limits of detection .103 Also the raw 
distillate analyses for pH, ammonia, phenols, and TOC did not meet the hygiene specifications. ^3 
For the post treated distillate, pH, ammonia, and phenols exceeded the hygiene specifications. 
Since no microbial controls were incorporated in these tests, the results were not useful except in 
the case of the post treated distillate which showed an increase in bacteria contamination which 
shows that carbon contained in the post treatment bed is providing nutrients for promoting bacterial 

growth. 103 

In the 1987 system integration Extended Metabolic Control System Tests, the raw and post 
treated distillate did not meet the hygiene specifications for pH, cadmium, iron, lead, magnesium, 
manganese, nickel fluoride, and TOC. 103 a more complete test plan is recommended to determine 
raw distillate quality, and additional organic analyses will be needed to further identify organic 
compounds present. Additional analysis methods need to be developed to determine dissolved gas 

and sulfides in water. 103 


4.6.5. 3 Vapor Compressor Distillation Subsystem (VCDS) 

The VCDS separates water by using a rotating drum whose inside is maintained at a 
reduced pressure. (See Figure 27). Vapor is compressed to raise its saturation temperature and 
pressure, and directed to the outer wall where it condenses on a surface which is in contact with the 
evaporator. Latent heat is transferred via conduction through the wall of the drum to the waste 
water inside, and is sufficient to evaporate an equal mass of water from wastewater. 44,48 
Unevaporated waste water is recirculated and stored as brine for return to Earth .44 The VCD 
process has water recovery efficiencies greater than 95% from urine with 98.5% possible when 
processing wash water.48 

The process control and monitoring is provided by motor-driven valves and in-line 
sensors. The condensate is pumped past a conductivity sensor which provides initial product water 
quality monitoring and controls a diverter which is activated when water quality is measured 
unsatisfactory. Any unsatisfactory water is reprocessed. 48 
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Source: Zdankiewicz, E.D., and J. Chu. 1986. "Phase Change Water Recovery for Space Station Parametric Testing 
and Analysis," SAE 860986. 48 

Figure 27. Vapor Compression Distillation Subsystem Schematic 
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4.6.5.4 Vapor Phase Catalytic Ammonia Removal (VPCAR) 


The VPCAR process was developed to produce potable water from unpretreated urine. 
The process is based on a catalytic chemical process whereby the impurities vaporizing with the 
process water are oxidized to innocuous gasses products. The VPCAR water recovery subsystem 
consists of the following components: 

* Hollow fiber membrane evaporator 

* Vapor blower/compressor for gas stream recycling 

* Catalytic reactor for ammonia & hydrocarbon oxidation 

* Porous tube water vapor condensor 

* Catalytic N 2 O decomposition Reactor 

The breadboard system produces higher quality water, has lower requirements for 
expendables, and accumulates less sludge than the VCD or TIMES recovery systems. Even with 
non-optimized commercial components, the VPCAR is competitive with the TIMES & VCD in 
weight .volume and power requirements. 68 


4.6.5.5 Multifiltration 

In MF water flows through a series of particulate filters which remove solids, adsorption 
beds which contain sorbents that remove nonpolar, organic contaminants, and ion exchange resin 
beds which remove ionized inorganic contaminants such as salts, metal and carboxylic acids. 44 
Current development is focusing on the best combinations of sorbents and resins to be used. 


4.6.5. 6 Reverse Osmosis 

The RO system reclaims waste water by passing the water through a semipermeable 
membrane in a direction opposing normal osmotic flow. The dissolved and suspended material is 
retained in a brine solution which is held for return to Earth or reprocessed through the TIMES or 
VCD subsystems. 
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4.6.6 Subsystem Cleanliness 


In a closed loop system it is essential to keep the system clean of contaminating organisms 
and chemicals. The use of traditional chemical biocides, disinfectants, cleansing agents and 
solvents may not be practical in a closed loop system because of creating waste neutralization and 
disposal problems, and ineffectiveness in eliminating organisms. 44 To prevent contamination 
laboratory-derived waste water will not be sent to the WRM subsystem. To control microbes 
within processing units, one approach is to incorporate a high temperature spike at the inlet using a 
heater/regenerative heat exchanger. Also at various waste water/process water/product water 
interfaces Microbial Check Valves will be used to impart a residual iodine concentration to product 
water at an approximate 2 ppm concentration. (See Figure 28). 

To insure system cleanliness both process monitoring and water quality monitoring will be 
performed. Process monitoring will involve tracking a few parameters such and pH, conductivity, 
organic carbon, and iodine to determine if components of the process are operating properly. 
Water Quality verification requires testing of over 60 chemical and microbial parameters. 44 a 
major thrust of this development is in the microbial monitoring of water quality. Current traditional 
methods may take up to 48 hours to complete, as well as have problems of sample volumes, 
sampling equipment, storage and disposal of media, etc. For these reasons, the amount on on- 
board verification will need to be minimized, and methods for more rapid verification need to be 
developed. 


4.6.7 Water Thermal Conditioning 

The WRM provides water thermal conditioning services to most of the Manned Systems 
facilities. There are three concepts for the optimum combination of centralized and/or distributed 
water heating functions: centralized batch heating, distributed batch heating, and distributed on- 
demand heating. The first would recognize a power savings, but would require rigid scheduling ot 
hot water usage, insulated distribution lines, and more sophisticated control. Although distributed 
batch heating would provide more usage flexibility, there would be maximum weight and volume 
penalties. The on-demand system would require significant power. These concepts are still being 

researched .44 
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Figure 28. Iodine Monitor Schematic 
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4.7 ECLSS Application Software 


4.7. 1 Command and Control Architecture 

The onboard command and control architecture implemented by ECLSS applications is 
hierarchical consisting of four levels (or “Tiers”) of operational management. These range from 
Tier I, the highest and most generalized level of operations management, to the very task specihc 
Tier IV operations management 5.6 


4.7. 1 . 1 Tier I Software (Top Level) 

Tier I provides for the integration of systems, elements, and payloads. It operates at station 
level and consists onboard of the crew and Operations Management Application (OMA) and on 
ground of the Operations Management Ground Applications (OMGA), station operators and 
payload operators on the ground, the Space Station Control Center, and the Payload Operations 
Integration Center. (See Figure 29) ^>6 


4.7. 1.2 Tier II Software (System or Element Manager) 

The ECLSS Manager is located at Tier II. Its primary responsibility is to coordinate the 
activities of each of the six subsystems of ECLSS across all of the pressurized modules. This 
control includes operation within assigned operational envelopes, monitoring the system health and 
status, and performing Failure Detection, Isolation, and Recovery (FDIR). It is this coordination 
that accomplishes the station-wide functioning ECLSS. 5,6 


4.7. 1.3 Tier III Software (Elemental Level) 

The third tier is located at the element level. The element ECLSS manager coordinates and 
controls ECLSS functions across rack boundaries. They are designed to be autonomous within 
that element, but are capable of working with the Station level ECLSS managers when necessary. 
The responsibilities of the element ECLSS managers shall include:^ 

A. Command and control, including data handling and command checking and 
verification. 
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Figure 29. Operations Management System (OMS) Functional Design 
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Command and control, including data handling and command checking and 
verification. 



B. Provision for appropriate manual overrides, dynamic limit setting, and 
process activation and inhibition. 

C. Fault detection, isolation to the ORU level, and recovery including corrective 
action response and emergency reconfiguration control. 

D. Detection of all critical system failures. 

E. Performance and trend data analysis. 

F. Provision of static display data for system monitoring, command and 
control. 

G . Updating of dynamic display data. 

H. Monitoring and reporting of the status and health of the ECLSS subsystems 
within the element to Tier II. 


4.7. 1.4 Tier IV Software (Rack Level) 

The fourth tier is located at the rack level. The rack level ECLSS Managers monitor and 
control the ECLSS functions within each rack of the element. This layer interfaces with Tier III to 
complete the ECLSS architectural structure. 


4.7.2 Data Management System (DMS) 

Provides: 

1. An application processing, process control and data handling environment for 

onboard systems, elements, and payloads. 

2. Software that permits the integration of the operations environment. 



Hardware Resources: 


1 . Application and network communication processors 

2. Mass storage units 

3. Electronic work station components for control and monitoring. 

4. Data acquisition and distribution components. 

Software Resources: 

1. Operating system and ADA ran time environment. 

2. Communication services. 

3. Data Storage and retrieval services. 

4. Data acquisition and distribution services. 

5. Time distribution services. 

6. Crew interface services. 
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4.8 ECLSS Subsystem Integration 


The configuration of the ECLSS is a closed loop which will result in lower orbit weight 
and resupply penalties.™ (See Figure 2). With the ECLSS configuration being a "racetrack" 
design, the equipment is physically distributed to be able to operate while sustaining a loss of a 
module, thus fulfilling the "safe haven" requirements. The design functionally centralizes 
equipment where possible, particularly where systems can be extended through the docking ports, 
and there are no fluids transport or contamination concerns. 88 The potable and hygiene water 
subsystems are centrally located in the two HAB modules and provide services to multiple Space 
Station Freedom elements. Urine and fecal collection and processing will be located in the 
HAB and LAB modules. 88 The AR is centrally located and is connected to other Space Station 
Freedom elements through the intermodule air distribution system.88 Hydrogen gas and carbon 
dioxide are not distributed between modules due to safety considerations. Oxygen and nitrogen are 
centrally distributed. All other ECLSS functions provide their services only in the Space Station 
Freedom element where the subsystem is located. 

"Safe Haven " is a big consideration in the location and distribution of subsystems. 
Subsystems that are functionally distributed, being only in the Space Station Freedom element 
where the subsystem is located, are redundant within that element. Under safe haven systems must 
be able to support emergency operating conditions for 45 days. 88 Safe Haven conditions are met 
either by redundancy of life critical functions, or by use of alternate technology equipment. Safe 
Haven is instigated after two non-repairable failures of a safety-critical subsystem, or after the loss 
of any single module. Therefore, safety-critical subsystems must be located in two modules. 107,5 
The two U.S. modules are the designated safe haven elements, so each element must be able to 
support the entire eight person crew under emergency operating conditions. 88,107, 5 The crew 
safety critical subsystems are CO 2 removal, CO 2 reduction, O 2 generation, and potable water 
reclamation. 

Stand alone and integrated system testing has been performed. Three integrated tests during 
the 1988 Phase II program were successfully performed. The 1989 Phase III program is aimed at 
enhancing the water reclamation system. Major issues of the Phase III tests include maintaining 
microbial and chemical cleanliness during extended duration simulations. 
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4.9 ECLSS Subsystem Interfaces With Other Systems 


The ECLSS interfaces with many other modules and systems, the primary ones being with 
the laboratory modules, manned system habitability, Extracvehicular Activity (EVA), and 
pressurized module attached payloads. ECLSS design has been influenced by these 
interfaces.70(See Figure 30). 
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Source: Ray, C.D., and W.R. Humphries. 1986. "Status of the Space Station Environmental Control and Life 

Support System Design Concept," SAE 860943, 16th Intersociety Conference on Environmental Systems, 
July 14, 1986. 20 


Figure 30. ECLSS Interfaces 
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5.0 DETAIL OF POTABLE WATER SYSTEM 


The following potable water treatment subsystem description is as defined in Appendix A 
document #114 "Phase III CMIF Recovery System/Facility Design Requirements" dated 
November, 1988; prepared by R. Bagdigian, and approved by W.R. Humphries and J.L. 
Vaniman. This baseline design configuration includes those subsystem technologies deemed most 
likely to produce product water meeting NASA Space Station Freedom water quality requirements 
at this time. For the most part the technologies chosen are those which have resulted from a 
relatively large amount of development work. These subsystems currently exist as advanced 
prototype hardware. The potable water system is still under development, however, and the reader 
should keep in mind that alternative technologies exist for many of these processes and 
development work currently under way may produce alternative subsystem hardware with superior 


performance characteristics. 

The Potable Water Multifiltration Subsystem (PWMFS) produces potable-grade water from 
a mixture of humidity condensate, carbon dioxide removal by-product water, and carbon dioxide 
reduction water. (See Figure 31). In the first half of the process, known as the sterilizer assembly, 
the waste water enters the PWMFS through a shutoff valve to a positive displacement gear pump. 
Positive displacement gear pumps are a form of metering pump which insures a constant volume 
flow rate at a particular pump speed setting. The pump feeds the water through a regenerative heat 
exchanger, heater, and heater reservoir which sterilize the water by heating the water to 250°C for 
20 minutes. A back pressure regulator maintains the pressure between 37.5 and 37.0 psig to 


prevent steam formation and assure the desired biocidal action. There are four temperature 
sensors, one pressure transducer, and a high and low level sensor in the feed tank. ^ 

In the second half of the process the water flows through a 2 micron prefilter for particulate 
removal, and a series of six identical sorption beds (Unibeds) which are packed with sorbents and 


resins that remove dissolved contaminants. Specific sorbent types and function, in order of flow 


are as 


follows;52,14 


Sorption Media 

Function 

Amount 

(l)MCV-L 

Polyvinyl pyrolidone (PVP) iodine 

96 r. 

(2) IRN-77 

Strong acid cadon resin 

90 r. 

(3) IRA -68 

(Undefined ?) 

60 r. 

(4) 580-26 

(Undefined ?) 

535r. 

(5) XE-347 

(Undefined ?) 

70 g. 

(6) APA 

Acdvated carbon 

64 g. 

(7) XE-340 

(Undefined ?) 

70 8 . 

(8) XAD-4 

Polymeric absorbant 

60 g- 

(9) IRN-150 

Strong acid/base mixed resin 

90 g. 

(10) MCV-H 

PVP iodine ? 

97 r. 

(11) IRN-77 

Strong Acid cauon resin 

90 r. 
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Figure 31. Potable Water Multifiltration Subsystem (PWMFS) Schematic 
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There are pressure sensors before and after the prefilter, conductivity sensors before the 
first, second, and third Unibed, and after the sixth Unibed; sample ports after the prefilter and the 
first 5 Unibeds; and a flow totalyzer after the last Unibed. Effluent exits the subsystem through a 
manual shut off valve and is delivered to a product tank. The product tank also has high and low 
level sensors. 14 When the first Unibed becomes saturated it is removed from the system and the 
valves are reconfigured to move the remaining beds up in position with a fresh bed placed in the 
last position. .52 There are manual on/off switches on the pump and on the resistant heaters in the 
heater and heat reservoir. There is also automatic control of the pump on/off control which is 
controlled by float sensors in the feed and product tanks. The pump is turned on when the high 
level sensor in the feed tank is activated, and is turned off when the low level sensor in the feed 
tank is deactivated or the high level sensor in the product tank is activated. 14 The third temperature 
sensor on the Heat reservoir controls the flow to the heater by sending signals to a temperature 
controller at the control monitor panel. If maximum allowable temperatures of 255°F are 
exceeded, and alarm signal sounds, but no automatic action is taken. 14 

The conductivity sensors, which measure water quality, control the pump by sending signals to 
two conductivity controllers at the control monitor panel. The pump is automatically stopped when 
the first Unibed is shown by the conductivity sensors to have exceeded its conductivity limits. The 
process is also automatically shutdown when the outlet conductivity exceeds 10 micromohs/cm. 14 
Manual shutdown of the entire system is controlled by a power switch on the control panel, which 
overrides all other controls. 14 
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APPENDIX A - Annotated Bibliography 

I.) UAH Preliminary Research Task (Flow Diagram). ECLSS Advanced Automation Project. 
NASA/MSFC. 


2. ) Year/(FY 89) Task Schedule (Chart) ECLSS Advanced Automation Project. 

NASA/MSFC. 

3. ) Space Station Freedom Advanced Development Project Plan. The Environmental Control 

and Life Support System Advanced Automation Project. Dewberry, Brandon S. NASA/MSFC. 

4. ) A Review of Space Station Freedom Program Capabilities for the Development and 

Application of Advanced Automation. 

Bayer, Steven E. et al,. December 1988. 

Page ix presents the idea of the Integrated Communications Officer [INCO] Expert System Project 
[IESP]. (See also page 44.) This may provide a good idea of the layering of the software system. 
It should also give us some idea of the kinds of considerations that are relevant to the Space Station 
project. Page 13 describes the Operations Management Application [OMA]. HABOMA is the 
Habitat OMA. Page 15 describes the Procedure Interpreter. This one sounds like a winner for a 
KBS. It is designed to present procedures in context, that otherwise would be hardcopied into the 
Flight Data Kit. It seems as though this Interpreter would leverage the ideas of Joshua and 
Concordia. Page 47 begins the discussion of the Software Support Environment. This is a good 
background for the Distribution charts. Page 57 begins a discussion of the Evolution of Advanced 
Automation. This is a good background for understanding the ideas of hooks and scars. Appendix 
A, beginning on page 75, gives a taxonomic presentation of AA efforts. We should have a section 
of our report that fits our work into the taxonomy. 

5. ) Environmental Control and Life Support System Architectural Control Document NASA 

Marshall Space Flight Center, February 15, 1989. 

Page 3-3 and 4 contains a brief definition of of the WRM. This is the subsystem in which potable 
water is contained. See also 3-8 and 3-9. ECLSS applications software begins on 3-10. Note that 
the idea of "Tiers" supports the idea that the context diagrams are hierarchical. Page 3-16 through 
3-17 present some shalls for the WRM. It would be good to compare these to NASA 3000 
extracts. Table 3-1 (page 3-34) provides some of the specifications for what WRM should do. 
Need definitions of lbm, person-day, HMF, and PEP. Note that tables 3-4 and 3-4a present the 
intriguing issue of what to do about experimental animals. Figure 3-1, page3-46, presents a 
diagram that on the left hand side seems to indicate the layout of parts for potable water and WRM. 
See Figure 3-6, page 3-5 1 , for specific schematic of WRM. 

6. ) Architectural Control Document Data Management System Part 1: Integrated Avionics 

Preliminary Draft Copy. NASA, December 15, 1989. 

Note the specification of DMS services on page 3-3 and the material on pages 3-17 and 3-18 for 
ECLSS (where avionics appears). 
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7.) Architectural Control Document Data Management System Part 2: Operations Management 
System Preliminary Draft Copy. NASA, December 15, 1989. 

If we understand this, correctly ECLSS itself should be considered a system manager. See pages 
6-8. Note two types of system manager page 1 1-12. The OMA and OMGA are described and this 
can give a better idea of the overall OMS. OMA ECLSS characterized again on page 15. The Table 
3-1 of Tier II managers is important. The column for DMS and ECLSS indicate what sorts ot 
things might be provided on which a KBS might operate and what sorts of things ECLSS should 
be able to do. Much of the areas listed are TBD. Table 3-1 is very important. 


8.) Architectural Control Document Data Management System Part 3: Data Management 
System. Preliminary Draft Copy. NASA Space Station Freedom Program, Office Reston, 
Virginia, December 15, 1989. 

Hooks and scars defined! A hook is a design accommodation to facilitate the addition or update of 
computer software at some point after the start of station operating life. A scar is a hardware hook. 
This document is primarily about hardware. Software begins on page 3-32. The Management 
section that begins on page 3-42 indicates the kinds of things that are offered in general to a 
manager. The services seem designed to make any particular software item an imbedded item. This 
is a reasonable conclusion since Ada is supposed to be for imbedded systems. 


9. ) Space Station Advanced Automation Study Final Report. Strategic Plans and Programs 

Division, Office of Space Station, NASA Headquarters, 

May, 1988. 

This is a most helpful document. Sections 2 and 3 seem to be the most important. Page 3 gives the 
clearest account of the specifics that we must to some degree satisfy. Note for example that page 23 
begins a discussion of what was NOT selected for baseline. 

10. ) Ada and Expert Systems. Allen, Bradley P, Inference Corporation. 

Seems to say what INFERENCE wants to do. They made the split between imbedded real-time 
systems and decision support systems. 

Defines two types of ADA expert systems as embedded real-time systems and decision support 
support systems. Lists problems in ADA expert system shells: 

a) size of the executable code 

b) run-time memory utilization 

c) unpredictable response times 

Describes transitional development from C and ADA tool to a stand alone ADA development tool. 

11. ) Art/Ada Design Project - Phase I Project Plan. Status Report. March 1988 - October 1988 
Allen, Bradley P. Inference Corporation October 24, 1988. 

Most of the information addresses specifically the development of ART using ADA. However 
some general considerations for expert system development are also listed. 
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12. ) ART/Ada Design Project - Phase I Task 1 Report: Overall Design. Status Report. March 

1988 - October 1988 Allen, Bradley P. Inference Corporation October 24, 1988. 

These articles document the progress made in the ART/ADA development. This tool is a more 
robust development tool than CLIPS, But for our purposes CLIPS should provide an adequate 
amount of flexibility. 

13. ) ART/Ada Design Project - Phase I Task 3 Report: Test Plan. Status Report. March 1988 
- October 1988 Allen, Bradley P. Inference Corporation October 24, 1988. 

See Article 12. 

14. ) Test Plan for Potable Water Multifiltration Subsystem Checkout and Performance 
Verification. McGriff, C. F. and Carter, D. L.December 19, 1989. 

This test plan gives an excellent description of the PWMFS hardware and operation. The PWMFS 
will produce potable grade water from humidity condensate and C02 reduction water. This 
subsystem consists of a heat exchanger - sterilizer fed by a gear pump , a 2 micron prefilter and 
five UNIBED mixed exchange resin filters. The subsystem is controlled via 4 thermocouples, 3 
pressure transducers, 2 level sensors, and a total flow meter. Diagrams and schematics are 
included. Subsystem designed by Umpqua Research Company for Boeing Aerospace. 

15. ) AI Applications for the Space Station. Culbert, Chris etal. NASA/Johnson Space Center, 

1988. 

General background. 

16. ) ECLSS Advance Automation Project. 

General background. 

17. ) TES - A Modular Systems Approach to Expert System Development for Real-Time Space 

Applications. Cacace, Ralph and England, Brenda. United Technologies Corporation. 

General background. Illustrates the application of several common techniques. 

18. ) Simulation and Control of a Space Station Air Revitalization System. SAE Technical 

Paper Series. 871425. Yandsy, James L. and Rowell, Lawrence F. 17th Intersociety Conference 
on Environmental Systems. July 13,. 1987. 

Describes the G 1 89A computer simulation tool for simulation and control of a space station air 
revitalization system. One of a variety of software tools developed by Langley for design 
.development, test, and engineering (DDT&E).Gives a good text and graphics description of an 
early proposed Space Station ARS. One typical group of technologies and plumbing configuration 
was modeled as a baseline for later comparison with other technologies. 

This document gives a good general overview of candidate technologies and basic concepts for an 
ARS. Some helpful baseline data such as: 

* Atmosphere leak rates 

* Atmosphere replenishment tank volumes 

* 02 consumption & 

* C02 production - relative to crew size 
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19. ) Environmental Control and Life Support Testing at the Marshall Space Flight Center. SAE 

Technical Paper Series. 871453. Schunk, Richard G. and Humphries, William R. 17th 
Intersociety Conference on Environmental Systems. July 13, 1987. 

20. ) Status of the Space Station Environmental Control and Life Support System Design 
Concept. SAE Technical Paper Series. 860943. Ray, C. D. and Humphries, W R. 16th 
Intersociety Conference on Environmental Systems. July 14, 1986. 

Good review of ECLSS. Page 5 indicates in a broad way the services that the ECLSS modules 
provide. Not that on page 8 it is clearly indicated that potable water comes from condensate. 

21. ) Artificial Intelligence Research and Applications at the NASA Johnson Space Center. 

Healey, Kathleen The AI Magazine, August, 1986. 

A general discussion of a variety of issues. Page 109 the ESRA and CCM are of interest. 

22. ) Test Plan for Potable Water Multifiltration Subsystem (PWMFS) Checkout and 

Performance Verification. McGriff, C. F. and Carter, D. L.,Dec 19, 1988.) 

Duplicate of document 14 

23. ) A Method for Evaluating Candidate. Slagel, James and Wick, Michael, AI Magazine, 

winter 1988. 

The SLAGEL-WICK model ought to be fully integrated into the general NASA ideas about 
candidate systems. We are working on this and generating a hyperCard template. 

24. ) Space Station Program Interface Requirements Document (Software). IBM Systems 

Integration Division, November 15, 1988. 

Technical specs on software. There is a lot of detail in the sense of functions and facilities that 
should eventually be available. 

25. ) Space Station Program Software Requirements Specification for the Data Management 

System Standard Services. IBM Systems Integration Division, November 15, 1988. 

Technical specs on software. There is a lot of detail in the sense of functions and facilities that 
should eventually be available. Together documents 24 and 25 give a good account of the services 
offered by the distributed database. They in some ways provide a model for thinking about a 
distributed KBS. 

26. ) Artificial Intelligence, Expert Systems and Technology Working Group, Status, Plans, 

Schedules. Webster, Larry D., AIESTWG, February 22, 1989. 

Mainly a chat about a meeting but... The slides present a good deal of current information. For 
example there is a statement of goals. This is good since it lays out some general constraints. There 
are also lists of members and wish lists! Part of what we are doing is responding to some section 
of the wish list. 
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27. ) Space Station Reference Growth Configuration Data Book R&D Emphasis. Early 

Concepts Data Drop Review Draft. McDonnell Douglas, February, 1989. 

Purpose of this data book is to define the requirements for Space Station growth, identify growth 
concepts for Space Station subsystems, and to present configurations for orderly growth during 
Space Station evolution. The data book shall be used to support baselining of the reference growth 
configuration by the Space Station Program Levels I and II and to provide data to the Work 
Packages to insure proper implementation of hardware scars and software hooks which will allow 
a smooth transition from the Phase 1 configuration through a series of growth phases to insure 
proper implementation of scars and hooks. 

Phase I Growth Configurations: Space station growth is derived from mission accommodation 
analyses performed for two utilization emphases l)microgravity research utilization, and 2) life 
science research utilization. The accommodation analyses were based on two transportation 
models: 1) moderate transportation support model, and 2) aggressive transportation support model. 
Four mission accommodation scenarios were evaluated. Evolution growth blocks are used to show 
incremental growth steps for space station systems such that a balance of resources is provided so 
that excesses or deficits are avoided in resources such as power, crew and pressurized volume. 
Components are added to the Space Station with reference to operating year and transportation 
support. Growth elements include: Solar Dynamic Modular pair. Transverse Boom Extensions, 
Orbital Maneuvering Vehicle, Resource Nodes, Hab Modules, Crew Emergency Return Vehicle, 
Keel Booms, Customer Servicing Facility, Docking Masts, Lg Pocket Lab, Lab Module, Space 
Transfer Vehicle Hanger, Back Porch, and Sm Pocket Lab. 

Space Station Subsystem growth requirements: 

Describes configuration of Module growth patterns. No specifics were given on Mechanical 
Systems, Utility Distributions, the Communications Tracking System, Airlock, Operations 
Management, Mobile Servicing Center, or attached Payload Accommodation, and are to be 
supplied later. Under Customer Servicing the transverse boom will be scarred to accommodate full 
development of the Space Station module patterning while maintaining National Space 
Transportation System (NSTS) cargo transfer capabilities. 

Appendices: 

A: Table 4 shows a Resource Allocation to R&D 

B: Shows Resource Allocation functions and equipment weights going up and returning 
after completion. 

C: Shows distribution of Space Station Resources and resource balance for the 
microgravity research utilization emphasis, moderate and aggressive transportation 
growth scenario; and life sciences utilization emphasis, aggressive transportation. 

D: Contains time-phased growth block analysis of the mission accommodation scenarios. 

28. ) Rack and Subsystem Level Schematics. Carter, Charve. Boeing Aerospace. Along with 

ECLSS Subsystem Groups and General Regenerative ECLSS Flow Diagram. 

This paper is a good general overview of ECLSS subsystems.The "General Flow Diagram" (same 
as in Doc. #1) is helpful and easy to read, everyone should look at this. Individual module 
schematics are quite complex and copy quality makes them nearly cryptic (will continue in depth 
analysis per weekly status.) 

SIX ECLSS SUBSYSTEMS 
1 . THC- temperature and humidity control 

A. temp & humidity control 

B. Avionics cooling 

C. Process air 

D. Thermally conditioned storage (TCS) 
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2. ACS - atmosphere control and supply 

A. pressure control 

B. Composition control& monitoring 

C. gas storage 

D. Vent & relief 

3. AR - atmosphere revitalization 

A. C02 removal 

B. C02 reduction 

C. 02 generation 

D. trace contaminant control 

E. trace contaminant monitor 

4. WRM - water recovery and management 

A. potable recovery 

B. hygiene recovery 

C. urine water recovery 

D. water quality monitor 

5. WM - waste management 

A. fecal processing and storage 

B. return waste storage 

6. FDS - fire detection and suppression 

A. fire detection 

B. suppressant storage (C02) 

C. suppressant distribution 


The first of three Basic Schematics show the ECLSS subsystem groups with it's six groups 
contributing to the space station: Temperature and Humidity control (THC), Atmospheric control 
and supply (ACS), Atmospheric Revitalization (AR), Water Recovery and Management (WRM), 
Waste Management (WM), and Fire Detection and Suppression (FDS). The second schematic is 
the general regenerative ECLSS Flow Diagram which shows how some of these subsystems 
interact to recover potable water from Urine recovery, waste water and product water recovery, 
and humidity condensate and process air. The third schematic shows the ECLSS schematic in 
more detail including where subsystems will be used in the different Nodes and Modules. ACS, 
THC, and FDS are components of all modules, and are the only subsystems in the Nodes, 
Hyperbaric airlock, and airlock. The logistics module has in addition to those three. Thermal 
condensate storage. The Lab Module and the HAB Module have all six subsystems, and AV air, 
with the HAB module also having Thermal condensate storage. There are no indications on any of 
these three schematics as to computer driven processes. 

Rack and subsystem level schematics are shown in the remaining schematics. Many ot these have 
been reduced so much that they are illegible to someone who does not know the engineering 
symbols used by the preparer. Schematics are included for Hygiene Water Processors, Urine 
Processor/refrig. Film Locker Rack, Potable Water Processor, Atmospheric Revitalization, 
THC/TCS/Avionics Air, THC, WRM, Oxygen Distribution, Nitrogen Distribution, Vent relief 
assembly and pressure equalization, avionics air/log, HAB lab THC mechanical, HAB lab avionics 
cooling, and cabin air/avionics cooking mechanical. 

29.) Distribution Flow Charts. 

These are being set into hypercard. The stack will allow you to follow the path through the 
distribution. The materials in 31, 32, 33, and 34 hit similar topics. See the overview stack. 
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30. ) ART/Ada Design Project - Phase 1 Task 2 Report: Detailed Design. Status Report. 

March, 1988 - October, 1988. Allen, Bradley P. Inference Corporation, October 24, 1988. 

More Art/ADA see articles 1 1 and 12. 

31 . ) ECLSS Advanced Automation Preliminary Research Task, (overheads). NASA - MSFC. 

32. ) WPOl ECLSS Software Architecture. Berner, S. A., Boeing. April 26, 1989. 

33. ) Incorporation of Software Automation in ECLSS. PDT Briefing, April 10, 1989. 

There does not seem to be anything specifically relating to what we are doing. 

34. ) WP-1 ECLSS Data Management System. McCall, B. Boeing Aerospace. April 26, 1989. 

35. ) Water Monitoring Requirements, Current Requirements, and Subsystem Schematics 

36. ) Regenerative Life Support System Research and Concepts Progress Report During the 

Period of April 1988 - December 1988. By The Regenerative Concepts Team, Texas A&M 
University. Available in document library, (RI m-56) also from M. Kilgore. 

37. ) Regenerative Life Support System Research and Concepts Progress Report During the 

Period of September 1987 - March 1988 By The Regenerative Concepts Team, Texas A&M 
University. Available in document library, (RI m-56) also from M. Kilgore. 

38. ) Space Station Man-systems Integration Standards. NASA-STD-3000 Volume IV 

Baseline December 18, 1986. 

This document lists, in a very general manner how NASA would like the differing systems within 
Space Station to operate which doesn't help us much. However, this report does include one very 
interesting table of information. Figure 7. 2.2. 3. 2. 1-1 (page 7-3) lists the Potable Water Quality 
Limits. 

39. ) Space Station Environmental Control and Life Support Systems, Test Bed Program - An 

Overview Behrend, Albert F. Jr. 

NASA has established generic test bed capabilities in which ECLSS has been implemented. To 
demonstrate that regenerative processes is the best solution to consumables. Reviews the history of 
ECLSS testing to this point. The ECLSS Test Bed Facility had three elements: 1) ECLSS 
Development Laboratory, 2) ECLSS Component Endurance Laboratory, and 3) Integrated ECLSS 
Test Bed facility. The primary objective was to conduct a 90-day manned test by May 1988. 
Subsystems selected for test bed incorporation are oxygen generation using static feed solid 
polymer electrolyte water electrolysis, Carbon dioxide removal using electrochemical depolarized 
carbon dioxide concentrator, carbon dioxide reduction using Sabatier, and Potable/Hygiene water 
recovery using Vapor Compressor Distillation. Alternative tests will also be done, using in 
respective order: static feed water vapor electrolysis, solid amine water desorption, Bosch, and 
hyperfiltration/reverse osmosis. Maturity of new technologies will be demonstrated and, as such, 
will minimize program risk and permit intelligent programmatic decisions to be made. 
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40. ) Feasibility of Expert Systems to enhance Space Station Subsystem Controllers Malin, 

Jane T. and Nick Lance, Jr., Space Station Automation, Vol. 580, 1985 

This 1985 report discusses the need and practicality of applying expert system technology to a 
wide variety of controller and diagnostic systems. Table 1 (page 29) lists the controller functions. 
A C02 removal system was used in the development of a fault management expert system. The 
systems development, using KEE, is described. This might be helpful when it is time for our 
prototype development. 

41. ) Study and Approach on Artificial Intelligence Testing, Progress Report Prepared for 

Boeing Aerospace Company by Vanderbilt University December, 1988 

42. ) ECLSS Integration Analysis - Requirements Analysis of a Knowledge Based System 

(KBS) for the Space Station Environmental Control and Life Support System. MDC W5184. 
May 9, 1985 

Lists two types of ECLSS data: 

1) data normally processed by the Space Station DMS 

2) internal process data. 

The functions provided by the DMS are: 

* Process status and performance monitoring 

* Process command and control 

* Historical data storage/recall 

* Fault detection, isolation, and response (FDIR) 

* Redundancy Management 

Describes three tier ECLSS design. The STATION LEVEL ECLSS will interface with the OMS 
which will more than likely be originally located on the ground. On page 2-2 a list of eleven 
functional requirements of the OMS and a system schematic. The primary objectives of an ECLSS 
KBS is to reduce and supplement manpower and to reduce ECLSS hardware downtime. The 
typical tasks and areas for trend analyses are listed on page 3-1. The report contains a brief section 
on the AR and WRM subsystems that might be worth everyone reading. In this section some 
generalized applications are listed and measurement lists included. 

43. ) Environmental Control Life Support for the Space Station 860944, Miller, Craig and 

Kovach, Licia. Life Systems, Inc. 

Summaries of ECLSS trade studies are presented. The analysis included the identification of time- 
critical functions, redundancy (backup) management, definition of common subsystem interfaces 
and quantification of technology options for the process equipment. Each technology was 
characterized by its physical characteristics of weight, power, volume, heat rejection, etc. 

44. ) Status of the Space Station Water Reclamation and Management Subsystem Design 

Concept. SAE 871510. Bagdigian, R. and Mortazavi. Life Support Branch, Marshall Space 
Flight Center, Huntsville, AL. 1987. 

The current status of the Space Station Freedom water reclamation and management (WRM) 
subsystem is outlined. The requirements and general architecture of the WRM are described. The 
main function of the WRM subsystem is to provide a safe, reliable supply of water to meet Space 
Station Freedom needs, while minimizing water-related resource requirements. It describes the two 
grades of water: Potable (crew-ingestable) and hygiene (non-ingestable) and the current 
technologies being developed to produce these waters. Table 1 shows Functional and Performance 
Requirements, Table 3 lists the some 60 Water Quality Requirements. The WRM subsystem 
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includes processors to reclaim or recycle water from various wastewater sources, as well as 
hardware to monitor water quality, provide water thermal conditioning, and store and distribute 
water throughout the Space Station Freedom. Some technologies described are the Air Evaporation 
Subsystem (AES), the Thermoelectric Integrated Membrane Evaporation Subsystem (TIMES), the 
Vapor Compression Distillation Subsystem (VCDS), and the Multifiltration and Reverse Osmosis 
subsystems. Chemical and microbial control is discussed. Urine pretreatment and thermal water 
conditioning are briefly discussed. 

45. ) Environmental Control and Life Support Systems Technology Options for Space Station 

Applications. SAE 851376. Hall, John and Ferebee, Melvin, NASA Langley Research Center 
and Sage, Karen, Kentron International, Inc. Hampton, VA. July, 1985. 

46. ) Space Station Environmental Control/Life Support System Engineering. SAE 851375. 

Miller, C. and Heppner, D. Life Systems, Inc. July, 1985. 

47. ) Evaluation of Space Station Thermal Control Techniques. 860998. Hall, J. B. NASA 

Langley, and Colwell, Gene and Hartley, James Georgia Institute of Technology. 

48. ) Phase Change Water Recovery for Space Station Parametric Testing and Analysis. 

860986. Zdankiewicz, Ed and Chu, James, Life Systems, Inc. 

49. ) The Space Station Air Revitalization Subsystem Design Concept. SAE 871448. Ray, 

Ogle, Tipps, Carrasquillo, and Wieland, Life Support & Environmental Branch NASA Marshall 
Space Flight Center. 

Excellent source of information on the ARS. This paper describes the current status of the ECLSS 
Air Revitalization Subsystem (ARS). ARS design is outlined, performance requirements are 
provided and evaluations of the relative merits of each of the subsystem options. Also computer 
models which analyze individual subsystem performance are discussed. The level of MFSC 
testing is summarized. 

50. ) A Membrane-Based Subsystem for Very High Recoveries of Spacecraftt Waste Waters. 

860984. Ray, Retzlaff, Radke, and Newbold, Bend Research, Inc. Bend, OR and Price, NASA 
Johnson Space Center. 

51. ) Concepts for the Evolution of the Space Station Program. 860972. Michaud and Miller, 

General Electric/Management and Technical Services Co. Houston, TX and Primeaux NASA 
Johnson Space Center. 

52. ) Pre- and Post-Treatment Techniques for Spacecraft Water Recovery. 860982. Putnam and 

Colombo Umpqua, Research Co. Myrtle Creek, OR and Chullen, NASA Johnson Space Center. 

53. ) An Advanced Carbon Reactor Subsystem for Carbon Dioxide Reduction. 860995. 

Noyes, Hamilton Standard and Cusick, NASA Johnson Space Center. 

54. ) Integrated Waste and Water Management System. 860996. Murray, General Electric Co., 

Houston Operations and Sauer, NASA Johnson Space Center. 

This 1986 paper generally describes the IWWMS (Integrated Waste and Water Management 
System) that was developed by the AEC, Air Force and NASA. The system utilized distillation and 
catalytic oxidation processes for purifying waste water and microbial digestion and incineration for 
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waste solids disposal. With the renewed interest in Space Station Freedom, this system was 
reviewed for applicability, updating and possible synergism with other life support systems. 

55. ) System Aspects of Columbus Thermal Control. 860938. Laux, Beckman and Lawson, 

MBB/ERNO Raumfahrttechnik GmbH. 

56. ) Hyperbaric Oxygen Therapy for Decompression Accidents — Potential Applications to 

Space Station Operation. 860927. Pilmanis, University of Southern California, Catalina 
Hyperbaric Chamber. 

57. ) Columbus Life Support System and its Technology Development. 860966. Leiseifer, 

Skoog and Preiss, Domier System GmbH, Friedrichshaten , FRG. 

58. ) A Study of Sabatier Reactor Operation in Zero “G”. SAE 840936. Forsythe, Broome 

College, Verostko and Cusick Johnson Space Center, and Blakely, Hamilton Standard. July 
1984. 

This 1984 paper presents results of zero "G" computer model simulations of the Sabatier reactor 
operation. It concludes that the reactor will run significantly hotter in a zero "G" environment if 
cooling air flow is not increased to compensate for the loss of natural convection. It can be 
successfully operated in zero G with the three and five man loads for which it was designed. The 
requirement for motion of air in the inhabited areas of a Space Station Freedom would lead to 
improved performance. For eight and ten-man loads, increased cooling flow in the jackets and 
forced exterior cooling would improve the performance of the reactor. This may also be achieved 
by a larger reactor, the temperatures of the reactor exterior surfaces are affected more by the zero- 
gravity conditions than the interior catalyst temperatures. More recent papers have not shown the 
heat convection to be a problem. Possibly only of interest in a historical developmental aspect. 

59. ) Effects of Varying Environmental Parameters on Trace Contaminant Concentrations in the 
NASA Space Station Reference Configuration. 860916. Brewer, Vigyan Research Associates, Inc 
and Hall, NASA Langley Research Center. 

60. ) Space Station Life Support Oxygen Generation by SPE Water Electrolyzer Systems. 

860949. Erickson and McElroy, Hamilton Standard, Windsor Locks, CT. 

Solid Polymer Electrolyte (SPE) 02 generation by water electrolysis became practical in the late 
sixties with the introduction of fluorocarbon ion exchange membranes. Developed by Hamilton 
Standard under contract to NASA the SPE vapor feed electrolizer is capable of supplying 0.06 
lbs./hr. of 02 at 3000 psi. A design used in nuclear submarines was modified to eliminate rotating 
equipment, the pre-deionizer, and associated maintenance. The design uses the energy in the high 
pressure hydrogen produced within the electrolyzer to pressurize the input process water 3000 psi. 
without the use of a mechanical pump. 

61. ) Integrated Air Revitalization System for Space Station. 860946. Boyda and Miller, Life 

Systems Inc. and Schwartz, Ames Research Center. 

Life Science's produced a prototype ARS using EDC for C02 removal, SFE for 02 generation, 
and Sabatier reactor for C02 reduction. This integrated prototype was built and tested to investigate 
the effects of process interactions on the operation of component functions, and any benefits in 
terms of power, weight, and volume reduction. 

This report contains drawings of subsystem components and design characteristics such as power 
requirements. Of special interest is the fact that the integrated system includes 72 sensors and 27 
actuators. Details of these sensors are not provided in the drawings or text! 
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62. ) Automated Subsystems Control Development. SAE 851379. Block, Honeywell Space 

and Strategic Systems Div. Heppner, Life Systems Inc. Samonski and Lance, NASA Johnson 
Space Center. July 1985. 

This report, similar in content to doc. #111, describes the Automated Subsystems Control for Life 
Support Systems (ASCLSS) project. The system consists of a hierarchy of distributed controllers 
implemented with 1750A microprocessors and a high speed busing network. 

63. ) Nuclear Powered Submarines and the Space Station: A Comparison of ECLSS 

Requirements. 860945. Rossier, Martin Marietta Aerospace. 

An interesting article that doesn't contain much information of use to us. Basically a 
comparison/contrast of ECLSS subsystems. There are fundamental differences in mission, 
environment, and resupply logistics for the two vehicles. 

"At present, specific operational parameters,design requirements, and resource availability for each 
vehicle dictate differing technologies for some (I'd say most) aspects of ECLSS design." 

64. ) EDC Development and Testing for the Space Station Program. 860918. Boyda and 
Hendrix, Life Systems, Inc. 

The Electrochemical Carbon Dioxide Concentration (EDC) has also been called the 
Electrochemically Depolarized Cell. This subsystem produced by Life Systems Inc. under contract 
to NASA utilizes an electrochemical cell to transfer CO 2 from low partial pressure atmospheres 
into a stream of H2 and C02 suitable for reduction processing.. The EDC is fairly light (5 to 10 
lbs) and is a net producer of power (54 to 71 watts). This paper gives a good comparison of CO 2 
removal technologies, the EDC, SAWD, 2BMS (carbon mol sieve), and 4BMS (zeolyte) on page 
84. The EDC is the lightest, most compact, and a net power producer, and appears to be the most 
desirable technology. 

65. ) Evaluation of Regenerative Portable Life Support Systems Options. 860948. Ciocca, 

Gruman Space Systems. 

This Grumman Space System report gives baseline MMU support that must be supplied by the 
Space Station EVA Support Subsystem (ES). 2000 EVA hrs. per year are projected for payload 
servicing and station maintenance with 50% growth over the next five years. The Space Station 
ES would be similar to the STS facility with additional advanced electronics for built in test 
capability, caution and warning, communications and heads up display. 

66. ) An Evolutionary Approach to the Development of a CELSS Based Air Revitalization 

System. 860968. Huttenbach and Pratt, Nelson Space Services, Ltd. and Bucke LH 
Bioprocessing, Ltd. 

The Controlled Ecological Life Support System (CELSS) is designed to closely mirror the 
biological/ecological CO 2 reduction and O 2 generation processes found on earth as an alternative to 
conventional physio-chemical methods on long duration missions. This Nelson Space Services 
research report reviews the limitations of conventional systems and presents details for a solar 
powered Algal bioreactor on a comparative basis. This is basic pioneering work for a Mars 
mission. The technology is not well studied and is encountering some resistance from engineering. 
Systems of this type are not baselined for station use. 
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67. ) Physiological Requirements and Pressure Control of a Spaceplane. 860965. Lemaignen, 

Fagot, and Weibel, Avions Marcel Dassault-Brequet Aviation Saint Cloud, France. 

This paper presents baseline data from a computer model for an Atmosphere control and supply 
subsystem (ACS) for the European space plane Hermes. The model uses first order D.E.’s for 
each of four gasses in the cabin atmosphere. 

68. ) Development of a Water Recovery Subsystem Based on Vapor Phase Catalytic Ammonia 

Removal (VPCAR). 860985. Budinkas and Rasouli, GARD Div Chamberlain Mfg. Corp. and 
Wydeven, NASA Ames Research Center. 

The VPCAR process was developed to produce potable water from unpretreated urine! The 
process is based on a catalytic chemical process whereby the impurities vaporizing with the 
process water are oxidized to innocuous gasses products. The VPCAR water recovery subsystem 
consists of the following components: 

* Hollow fiber membrane evaporator 

* Vapor blower/compressor for gas stream recycling 

* Catalytic reactor for ammonia & hydrocarbon oxidation 

* Porous tube water vapor condensor 

* Catalytic N 2 O decomposition Reactor 

The breadboard system produces higher quality water, has lower requirements for expendables, 
and accumulates less sludge. Even with non-optimized commercial components, the VPCAR is 
competitive with the TIMES & VCD in weight, volume and power requirements. 

69. ) Air Evaporation Closed Cycle Water Recovery Technology — Advanced Energy Saving 

Designs. 860987. Morasko, AiResearch Manufacturing Co. Torrance, CA; Putnam, Umpqua 
Research Co., Myrtle Creek, OR; Bagdigian, NASA Marshall Space Flight Center. 

A wick feed air evaporator is presented as an alternative to the TIMES & VCD. A preprototype 
unit was produced by Airesearch Manufacturing Corp. in Conjunction with Umpqua Research 
under MSFC contract. The system is capable of 100% water recovery from urine, wash water, 
RO brine, etc. It utilizes a circulating air stream, air heater, wick evaporator, and condensing heat 
exchanger for reclaiming process water from heavily contaminated feed streams. Wicks load up 
with solids until capillary action is severely affected, the wick pads are then replaced and spent 
pads with the solid contaminants are placed in waste management for return. The system is light, 
rugged, and requires little power. Unfortunately wick pads must be delivered and returned from 
orbit indefinitely. 

70. ) Status of the Space Station Environmental Control and Life Support System Design 

Concept. 860943. Ray and Humphries, Life Support & Environmental Branch NASA Marshall 
Space Flight Center. 

This paper reviewed the status of the Space Station Freedom ECLSS as of 1986. This is an annual 
type report similar to that reported in document no. 88. It shows similar outlines of ECLSS 
subsystems and their functions. Table 2 has respirable atmosphere and water requirements. It 
discusses the reasons for deciding on the configuration of the Space Station Freedom and how 
ECLSS interfaces with other systems and modules. In configuration studies it was decided that 
closed loop configuration should be used to lower weight/volume requirements and lower resupply 
penalties. The distribution of the subsystems was studied. It was determined that FDS, ACS, and 
THC should be distributed equally in the two U.S. modules. Four AR and potable water recovery 
systems (two in each U.S. module) should be used. There are also tables of the ECLSS resource 
summary, resource requirements, and an 8 member crew mass balance presented. 
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71. ) Enhanced Evaporative Surface for Two-Phase Mounting Plates. 860979. Grote, Stark 

and Tefft, Me Donnell Douglas Corp. St. Louis, MO. 

72. ) A Space Station Utility — Static Feed Electrolyzer. 860920. Larkins, Wagner, and 

Gopikanth, Life Systems, Inc. 

The Static Feed Eletrolyzer 02 generation subsystem developed by Life Systems Inc. under 
contract for NASA, could generate 02 from water sources for use in ECLSS, Electrical power 
systems (EPS), and Extravehicular activities (EVA). In the ECLSS system alone the SFE might be 
used to generate metabolic oxygen, to provide reactants for CO 2 removal, and to generate 
hydrogen for CO 2 reduction. An SFE is also capable of generating H 2 /O 2 propellents for 
propulsion and reboost systems. 

The main focus of this report is to investigate systems commonality benefits. What weight and 
power benefits would arise from integrated SFE systems servicing several other station 
subsystems? Their conclusion was; "From every perspective user to system to design, the benefits 
of commonality introduced by using an integrated SFE O 2 /H 2 generation should be viewed as a 
utility to satisfy a wide range of space station requirements." 

The report includes drawings, photographs, and a technical description of the system. The module 
consists of a series of individual electrochemical cells stacked fluidically in parallel and connected 
electrically in series. 

The following control and support hardware is required: 

(1) Coolant Control Assembly - Provides a constant flow of controlled, variable 
temperature liquid coolant to the electrochemical module. 

(2) Pressure Control Assembly -Maintains absolute subsystem pressure, controls 
differential pressures required to establish and maintain the liquid/gas interfaces within the cell 
cavities and controls initial pressurization and depressurization. 

(3) Fluids Control Assembly - Controls and monitors the pressure and flow of water and 
N2 during steady state electrolysis and mode transitions. 

73. ) Regenerative Life Support System Hardware Testing — A Summary. 860941. Reysa, 

Boeing Aerospace Operations, Houston, TX. 

Quite a good report on the history and results of ECLSS competing subsystem technologies 
comparative testing.The following points are worth noting : 

1. The SFE was selected because it did not require a dynamic H20/H2 separator which had 
to be used in the SPE to prevent pump vapor lock. Baseline configuration designers chose the SFE 
to significantly reduce mechanical complexity and maintenance. 

74. ) Habitation Module for the Space Station. 860928. Johnson, Wolbers, and Miles; Me 

Donell Douglas Aeronautics Co. Huntington Beach, CA. 

75. ) Space Station Health Maintenance Facility. 860922. Harvey et. al. Lockheed Missiles & 

Space Co. Inc. Sunnyvale, CA. 

76. ) Design of an Oxygen Sensor with Automatic Self-Testing and Calibration Capability. 

860919. Kutschker and Taylor; Leeds & Northrup Instruments, A Unit of General Signal, and 
Cusick, NASA Johnson Space Center. 

77. ) Analysis and Composition of a Model Trace Gaseous Mixture for a Spacecraft. 860917. 

Schwartz and Oldmark, NASA Ames Research Center. 
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78.) An Expert Systems Approach to Automated Fault Diagnostics. SAE 851380. Lance and 
Matin, NASA Johnson Space Center. July 1985. 

An excellent report for us! A KBS fault isolation and recovery program called "FIXER" has been 
developed by Johnson Space Center (JSC) in Inellcorp's KEE tool for the ARS C02 removal 
subsystem, the electiochemically depolarized cell (EDC). This EDC version termed "CS-1” in the 
text was developed by Life Systems Inc. This EDC Hardware is described in Doc. #64. Their 
model did not treat multiple faults or fluid leaks, but was rather sophisticated in other ways. It was 
designed to operate in parallel with the actual hardware controller and was required to recover from 
potential fault conditions before the EDC module controller interupted operation at onset of a red- 
line condition. 

They chose a relatively small, simple, and well developed subsystem (hardware had been delivered) 
and their treatment reflects this. Their short, 12 man week effort produced a tool capable of 
extending periods of autonomous operation of the EDC in spite of any of 23 possible single fault 
conditions. 


79. ) Utility of an Emulation and Simulation Computer Model for Air Revitalization System 

Hardware Design, Development, and Test. SQE 851377. Yanosy; Hamilton Standard Div. 
United Technologies Corp, and Rowell; NASA Langley Research Center. 

80. ) Integrated Waste and Water Management System. 860996. Murray; General Electric Co. 

Houston Operations and Sauer NASA Johnson Space Center. 

81. ) Environmental Control and Life Support Technologies for Advanced Manned Space 

Missions. 860994. Powell and Wynveen; Life Systems Inc. and Lin; NASA Johnson Space 
Center. 

This paper is fairly outdated now. It presents some of the preliminary results of the study program 
of JSC to define ECLSS requirements for advanced space missions, identify unique mission 
drivers, develop trade methodology, assess existing ECLSS technology capabilities, identify new 
ECLSS technology needs, and establish a technology R&D plan. It also provides a brief history of 
the ECLSS throughout the U.S. manned space program. Table 5 lists performance requirements, 
but these are updated in other publications. Table 7 identifies ECLSS Mission Drivers by Mission 
Location and identifies those that are unique. They conclude that mission duration and crew size 
are large enough now to justify the use of regenerative ECLSS technologies, that these would lead 
to significant savings in initial and operational costs, but would take years of R&D efforts to 
obtain. Potential missions were identified and will require ECLSS technologies that avoid 
expendables and large resupply weight penalties. 

82. ) Atmospheric Contaminant Monitoring and Control in an Enclosed Environment. SAE 

881094. Strack, Electric Boat Division, General Dynamics Corp. July, 1988. 

Not very specific on use in space. The paper discusses the major contaminants expected to be 
found, discusses monitoring and control methods - but mostly based on experience in submarines. 
Very general about space environment applications. 

83. ) A Computer Aided Engineering Tool for ECLSS Systems. SAE 871423. Bangham, 

McDonnell Douglas Astronautics Co., Huntsville, AL and Reuter, Life Support Branch, Systems 
Analysis and Integration , NASA MSFC. . 
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84. ) G189 Computer Program Modeling of Environmental Control and Life Support Systems 

for the Space Station. SAE 871427. Baker, So, and DeBarro, Space Station Systems Div. 
Rockwell International Corp. July, 1987. 

This is another presentation of the material in Doc.# 18. 

85. ) Test Results of a Shower Water Recovery System. SAE 871512. Verostko et. al. NASA 

Johnson Space Center, and Reysa, Boeing Aerospace Operations, Houston, TX. July, 1987. 

A shower test was conducted at JSC in which waste water was reclaimed and reused. The waste 
water was purified using reverse osmosis followed by filtration through activated carbon and ion 
exchange resin beds. The reclaimed waste water was, after modification, maintained free ot 
microorganisms by using both heat and iodine. This paper discusses the limited effectiveness of 
using iodine as a disinfectant and the evaluation of a Space Station Freedom candidate soap for 
showering. There is a description of the RO used and the Umpqua unibeds used. They concluded 
that iodine was determined to not be an all inclusive disinfectant for all microorganisms. P. Capacia 
survived in the Shower Water Recovery System (SWRS) storage tanks disinfected with iodine. 
After modifications the use of heat disinfection at 185°F for 3 hours was shown to be effective and 
necessary for waste water recovery systems. They also concluded that RO with post-treatment 
provided acceptable recovered shower water for recycling. There were early breakthroughs of 
organic impurities in the Unibeds, this was remedied by larger sorption beds. Finally the soap 
may cause a gel layer to form on the RO membrane, further testing is recommended on the soap. 
During reuse test the water had an odor whose source needs to be identified. 

86. ) Initial Results of Integrated Testing of a Regenerative ECLSS at MSFC. SAE 871454. 

Jackson and Worden, Boeing Aerospace Co. and Johnson, AiResearch Mfg. Co. July, 1987. 

This paper gives the preliminary test results for integrated testing of ECLSS. Subsystems are 
described and plans for future testing outlined. All of this information is updated or covered in 
other articles already incorporated into the final report. 

87. ) Control/Monitor Instrumentation for Environmental Control and Life Support Systems 

Aboard the Space Station. 861007. Heppner, Khoury and Powell, Life Systems, Inc. 

88. ) Preliminary Design of the Space Station Environmental Control and Life Support System. 

881031. Reuter, Turner and Humphries, Life Support Branch, NASA MSFC. 

Excellent review article of status of the seven ECLSS subsystems with their brief descriptions and 
purposes. Discussion of "Safe Haven” and how this has affected the physical distribution, sizing, 
and interrelationship of subsystems. Some discussion of technologies still being developed and 
choices that will need to be made (may be useful in future technologies section of final report. 

89. ) Comparison of C02 Reduction Process -- Bosch and Sabatier. SAE 851343. Spina and 

Lee, Life Systems, Inc. Cleveland, OH. July, 1985. 

90. ) A Study of the Sebatier-Methanation Reaction. SAE 740933. Verostko, NASA Johnson 

Space Center, and Forsythe, Broome College. July-August, 1974. 

91. ) Regenerative Life Support Program equipment Testing. SAE 881126. Boehm, Boynton 

and Mason, Hamilton Standard Division, United Technologies Corp. July, 1988. 

This paper describes the integrated systems metabolic control testing of 4 subsystems developed by 
Hamilton Standard division of United Technologies: TIMES, Sabatier, SAWD, and SPE. 
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92. ) Initial Development and Performance Evaluation of a Process for Formation of Dense 

Carbon by Pyrolysis of Methane. SAE 851342. Noyes, Hamilton Standard, and Cusick, NASA 
Johnson. 

93. ) Phase Change Water Processing for Space Station. 851346. Zdankiewicz, Life Systems, 

Inc. and Price, NASA Johnson. 

94. ) Water Quality Monitor for Recovered Spacecraft Water. SAE 851347. Ejzak, Astro 

Resources International Corp., and Price, NASA Johnson. 

This paper describes a TOC analysis system based upon ultra-violet adsorption. Previous attempts 
to measure low levels of TOC involve the use of expendable and potentially dangerous chemical 
reagents. The unit currently under evaluation can handle extremely low level (2ppm) on a 
continuous basis. The sample is totally unchanged after exiting the unit. This state-ot-the art 
breadboard shows promise. This 1985 paper is very preliminary. Will look for more recent articles 
on TOC analysis. 

95. ) Static Feed Water Electrolysis System for Space Station 02 and H2 Generation. SAE 

851339. Larkins and Kovach. Life Systems, Inc. 

This paper describes the SFE subsystem for oxygen generation on the Space Station Freedom. 
The overall system dynamics and schematics are provided as well as development testing up to this 
point. Other documents have more up to date information on the status of this technology. 

96. ) An Expert Systems Approach to Automated Maintenance for a Mars Oxygen Production 

System. SAE 881056. Haung, Wei, Ash, and Ho, Dept, of Mechanical Engineering & 
Mechanics, Old Dominion Univ., Norfolk, VA. 

97. ) Maturity of the Bosch C02 Reduction Technology for Space Station Application. SAE 

880995. Wagner; Life Systems Inc., Carrasquillo: NASA MSFC, and Edwards and Holmes; 
Boeing. 1988. 

This paper describes the evolution of the Bosch C02 reduction subsystem. It concludes that the 
Bosch process is reaching a level of technological maturity demonstrating its viability for Space 
Station Freedom application. Some work remains before flight hardware is constructed, 
particularly improvements which will optimize weight, power, volume and maintainability. 

The Bosch technology is promising because there is no on-board gaseous storage or overboard 
venting required, and it is potentially 100% efficient. 

The Bosch process occurs at 426 to 726°C in the presence of a catalyst. Carbon dioxide combines 
with H 2 and produces carbon and water vapor in an exothermic reaction. A recirculating loop is 
required to attain good conversion efficiencies. 

A Bosch II design is currently in operation at the NASA MFSC.This design includes a cold seal 
Bosch reactor which eliminated the tremendous heat loss at the closure interface, and also 
eliminated the need for a vacuum interface. The entire process is contained within a disposable 
carbon cartridge. There is a recuperative heat exchanger that maximizes the Bosch thermal 
efficiency. 
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The Bosch subsystem is designed for completely automated operation. A Control Monitor 
incorporating microcomputer software technologies is used for automatic mode. The computer is 
required when switching between operating modes and for fault detection, fault isolation, fault 
prediction and built-in diagnostics for subsystem verification. 

98. ) Carbon Dioxide Reduction Processes for Spacecraft ECLSS: A Comprehensive Review. 

SAE 881042. Noves, Hamilton Standard. 

99. ) Using Hardware to Test the Space Station Water Reclamation and Management Subsystem 

in Zero-G. SAE 881018. Williams, Rockwell Shuttle Operations Company. 

100. ) Two-Bed Carbon Molecular Sieve Carbon Dioxide Removal System Feasibility Testing. 
SAE 880993. Kay, R.J. and Tom, R., Allied-Signal Aerospace, AiResearch Los Angeles Div, 
Torrance, CA. 

101. ) Environmental Control and Life Support Testing at the Marshall Space Flight Center. SAE 
871453. Schunk and Humphries, Life Support Branch, NASA MSFC.] 

This paper addresses the in-house MSFC development test program including both subsystem and 
system level activities. THC, ACS, and FDS were not emphasized because of previous extensive 
flight experience. EVA support is also not addressed. AR and WRM were the groups being 
addressed, with WM being performed at contractor facilities. Specific issues were water and 
oxygen reclamation and trace contaminant control. 

Development work in 1986-1987 was being done on a multifiltration unit for wash water recovery, 
and multifiltration tests on potable water reclamation. Air evaporation phase change urine 
reclamation was done by the contractor. 

System level tests included interactive testing of selected air revitalization and water reclamation 
subsystem equipment. The simulator and area is known as the Core Module Integration Facility 
(CMIF). Five subsystems were selected for system testing: TIMES (Thermoelectric Integrated 
Membrane Evaporation Subsystem), the 4-Bed Molecular Sieve subsystem, the SFE (Static Feed 
Electrolyzer) subsystem, the Sabatier subsystem, and the TCCS (Trace Contaminant Control 
Subsystem) Phase II testing, which was to conclude in 1987, contained five regenerative ECLSS 
subsystems located inside the simulator: a TIMES water reclamation subsystem, a SFE oxygen 
generation subsystem, a Sabatier carbon dioxide reduction subsystem, and a TCCS. Support 
hardware included a metabolic simulator, a near real time water quality monitor and a TSA (Test 
Support Accessory) for the SFE subsystem. 

102. ) An Efficient Air Evaporation Urine Processing System for Space Station. SAE 881034. 
Madsen; Allied-Signal Aerospace, and Putnam; Umpqua Research Company. 

103. ) Air and Water Quality Monitor Assessment of Life Support Subsystems. SAE 881014. 
Whitley, Carrasquillo, Holder and Humphries, NASA MSFC. 

This paper describes the status of the MSFC test program for the air revitalization and water 
recovery management subsystems. As of this date, the AR and WRM subsystems have not been 
defined. There was a Phase B preliminary design completed in 1986. ECLSS subsystem 
competitors were gathered at MSFC for testing prior to find selection. Independent and system 
level testing is being done. These tests included an oxygen reclamation subsystem string including 
the 4-bed Molecular Sieve (4-BMS) CO 2 removal unit, the Sabatier CO 2 reduction unit, and the 
KOH Static Feed Electrolyzer (SFE) oxygen generation unit Also tested was the Thermoelectric 
Integrated Membrane Evaporation System (TIMES) urine water recovery unit and a Trace 
Contaminant Control System (TCCS). Multifiltration and reverse osmosis were not available. 
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The goals of the tests were limited - the design did not incorporate any microbial control features 
and sample ports were not of an aseptic design, chemical evaluation was not done in a rigorous 
fashion and no effort was made in the test system design to meet hygiene water quality 
requirements for the TIMES product water. 

There were four major test activities in 1987: one independent subsystem test for each air and water 
subsystem and three separate integrated system tests. The first integrated test consisted of the air 
revitalization loop, the second and third termed Metabolic Control Test of 3 day duration, and the 
fourth an Extended Metabolic Control Test of 6 day duration. Results of theses tests and 
suggestions for future modifications were discussed. In conclusion, improved sampling techniques 
are needed to eliminate air contamination, a better method of quantifying water vapor percentage 
must be established, a real-time monitoring of ECLSS gases is needed among other things. 

104. ) Advancements in Water Vapor Electrolysis Technology. SAE 881041. Chullen, NASA 
Johnson Space Center, and Heppner and Sudar, Life Systems, Inc. 

105. ) Air Revitalization System Study for Japanese Space Station. SAE 881112. Otsuji, 
Hanabusa, Etoh and Minemoto; Mitsubishi Heavy Industries, Ltd., Japan. 

106. ) Technology Demonstrator Program for Space Station Environmental Control Life Support 
System. SAE 871456. Adams, Platt, Claunch, and Humphries, NASA MSFC> 

107. ) Space Station Environmental Control and Life Support System Distribution and Loop 
Closure Studies. SAE 8609452. Humphries, James, Reuter, and Schunk; NASA MSFC. 

This paper addressed the distribution among the modules of the ECLSS subsystems. The module 
resource requirements and safety implications, particularly with regard to safe haven operations 
was discussed. It also addresses the degree of loop closure, and the recommendation to close both 
the oxygen and water recovery loops. To determine the distribution of subsystems it was first 
determined whether the ducting and plumbing sizes would work in centralization configuration. 
Second, the number of units, design capacity, and physical location of the subsystems was 
examined. 

Safe haven is defined as the condition necessary to ensure survival of the crew for 28 days, while 
rescue is achieved. A safe haven operating condition can be instigated after two non-repairable 
failures of a given safety-critical subsystem, or after the loss of any single module. Because of safe 
haven, any centralized subsystem had to be physically located in two modules. Figure 1 8 shows 
the recommendations for whether a subsystem is physically centralized or distributed, and the 
locations of the subsystems. It was recommended that temperature control and intramodule 
ventilation be distributed, therefore each module would need a subsystem. Water, oxygen, carbon 
dioxide control, and contaminant control could be centralized. Humidity control was also 
distributed. Fire detection and suppression, module repressurization, and vent, relief and dump 
capabilities are required in each module. Hygiene water should be centralized. The air 
revitalization and potable water reclamation systems should be centralized, and these should be 
located in the two U.S. modules to satisfy safe haven requirements,. 


108. ) Controlling Real-Time Processes on the Space Station with Expert Systems. SPIE Vol. 
729 Space Station Automation II (1986). Leinweber, David; LISP Machine Inc. Manhattan 
Beach, CA, and Perry, John; OAO,Inc Segundo, CA. 1986. 

109. ) The Role of Expert Systems on Space Station. Proceeding of Conference held in Geneva 
in May 1986. Sloggett, Environmental and Space Systems Group, Software Sciences, UK. 
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110. ) System Autonomy Hooks and Scars for Space Station. SPIE Vol. 851, Space Station 
Automation III (1987). Starks and Elizandro, East Texas State University, CS Dept. 

111. ) Prototype Space Station Automation System Delivered and Demonstrated at NASA. 
NASA Conference Publication 2492. Block, Honeywell Space and Strategic Avionics Div., 
Clearwater, FL. 

The Automated Subsystem Control for Life Support Systems (ACLSS) was developed by 
Honeywell and Life Systems Inc., as a proof of concept of a generic automated controller for 
Space Station subsystems. This group chose the ARS subsystem (they call it the ARG, air 
revitalization group) to develop a proof of concept model. 

The developers claim "the delivered ACLSS demonstrated the automation of 1) three complex life 
support processes; 2) the monitoring and reporting of ARG system and process status, warning, 
and alarms; 3) the system event logging; 4) the fault detection and system safety; and 5) the 
calculation and evaluation of the current system operational performance parameters and 
efficiencies. 

112. ) Challenges in the Development of the Orbiter Atmospheric Revitalization Subsystem. 
NASA Conference Publication 2342. pt. 1. Prince, NASA Johnson; Swider et.al., Hamilton 
Standard; Ord and Walleshauser, Moog Inc. and Gibb, Rockwell International. 

Details of THC and ACS subsystems for the Space Shuttle are presented in this report , with 
particular emphasis on multimission capabilities of pumps and separators. Systems that require 
gravity driven fluid flow or convection cooling fail quickly in low g use, and some ingenious 
work-arounds are discussed. 

Specifically addressed are rotating elements, such as motors and liquid separators; and several 
pressure and atmosphere control components. Of particular interest is a valve position indicator 
discussed on page 421, and the flow sensor on pg. 422. 

113. ) Other Challenges in the Development of the Orbiter Environmental Control Hardware. 
NASA Conference Publication 2342 pt. 1 . Gibb and McIntosh, Rockwell International. 

This Rockwell Int. report discusses several problems encountered with Space Shuttle ECLSS 
subsystems, specifically the ammonia boiler system (ABS), smoke detector, water hydrogen 
separator, and the waste collection system (WCS). Of particular interest to us are the ABS, a heat 
exchanger to remove waste heat from avionics and other orbiter systems; the smoke detector, an 
FDS component; and the WCS, a WM subsystem. 

At altitudes below 120,000 ft. the ABS provides a means for rejecting waste heat loads into the 
atmosphere. When the ABS is operating, heat is transferred from the Freon 21 cooling loop by 
the evaporation of anhydrous ammonia, which is then vented overboard. Some similar system will 
be necessary to reject heat from space station systems, however overboard venting will probably 
not be acceptable. 

A piezoelectric microbalance type smoke detector was originally proposed for orbitor use, but 
calibration problems resulting from the extreme sensitivity of this device necessitated its 
replacement with an ionization type detector. 
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The waste collection system has undergone several evolutionary modifications to alleviate the 
problems associated with low gravity elimination. This section is rather humorous to those who 
have not dealt with this problem, but proper function of this equipment is important to health and 
crew moral. 

114. ) Bagdigian, R., and W.R. Humphries. 1988. "Phase III CMIF Water Recovery 
System/Facility Design Requirements". November, 1988. 

115. ) Rogers, J.S., D.M. Rochowiak, B.L. Benson, and J.W. McKee. 1989. "A Diagnostic 
Prototype of the Potable Water Subsystem of Space Station Freedom ECLSS," UAH Research 
Report Number 824, Johnson Research Center, University of Alabama in Huntsville, November 
1989. 

116. ) Rochowiak, Daniel. 1989. "Final Report: Cooperating Intelligent Systems", prepared for 
Walt Mitchell, Systems Software Branch, Information and Electronic Systems Laboratory, 
Marshall Space Flight Center, UAH Research Report Number 804, prepared by the Johnson 
Research Center, University of Alabama in Huntsville, August 1989. 

117. ) Daley, Phillip and Allison Thornbrugh. 1989. “Using Neural Nets To Automate 
Knowledge Engineering,” In Proceedings of Workshop on Knowledge Acquisition, IJCA1 KA, 
(Detroit) pp 1-4, 1989. 
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APPENDIX B - Detailed Context Diagrams 
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APPENDIX C 
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Environmental Control and Life Support Systems 
Preliminary Hooks and Scars Document 


Introduction 

The Environmental Control and Life Support System (ECLSS) for the Space Station Freedom 
(SSF) is responsible for maintaining an inhabitable living and working environment tor a crew ot 
up to eight individuals. Since the current design is for the SSF to recycle its life sustaining 
substances and to dynamically handle waste products, the ECLSS has evolved into a incredibly 
diverse and complicated system. The ECLSS is composed of the following six subsystems: 
Temperature and Humidity Control (THC), Atmosphere Control and Supply (ACS), Atmosphere 
Revitalization (AR), Water Recovery and Management (WRM), and Waste Management (WM) 
(figure 1). Each of the subsystems, while defined as an separate process, must be an integral part 
of the total ECLSS. This requirement along with the specific needs for computer assistance with 
the operation of ECLSS has generated the need for a review of the current design and 
implementation concepts for each of the subsystems. 

In April 1989, the staff of the Johnson Research Center (JRC) was contracted by NASA to begin 
an evaluation of each of the ECLSS subsystems to identify possible locations for additional 
computer software applications. Although the research effort is continuing, this report describes 
the software hooks and hardware scars that have been identified. Included within this report is a 
discussion on general considerations for expert systems and computer automation and basic 
communication considerations as they apply to all of the subsystems. Also included is a detailed 
examination of the potable water component of the WRM. 


What are hooks and scars? 

A hook is a design accommodation to facilitate the addition or the update of computer software at 
some point after the start of the SSF life. Thus, this research is actively searching for areas which 
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might not only be an immediate location for additional computer software applications, but also 
areas that might at sometime in the future be a viable location for some type of computer 
application. A scar is a hardware modification that would be required to accommodate the software 
hook. Since much of the actual hardware and software design is still undetermined at this time, 
many of the software hooks and hardware scars that are listed in this report are simply the minimal 
hardware requirements that a given software system would have. Therefore, many of the items 
identified in this report might not require additional changes to the system. 
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ECLSS SUBSYSTEMS 




1. THC- Temperature and Humidity Control 

A. Temp & Humidity Control 

B. Avionics Cooling 
C Process Air 

D. Thermally Conditioned Storage (TCS) 

2. ACS - Atmosphere Control and Supply 

A. Pressure Control 

B. Composition Control & Monitoring 

C. Gas Storage 

D. Vent & Relief 

3. AR - Atmosphere Revitalization 

A. C02 Removal 

B. C02 Reduction 

C. 02 Generation 

D. Trace Contaminant Control 

E. Trace Contaminant Monitor 

4. WRM - Water Recovery and Management 

A. Potable Recovery 

B. Hygiene Recovery 

C. Urine Water Recovery 

D. Water Quality Monitor 

5. WM - Waste Management 

A. Fecal Processing and Storage 

B. Return Waste Storage 

6. FDS - Fire Detection and Suppression 

A. Fire Detection 

B. Suppressant Storage (C02) 

C. Suppressant Distribution 




Figure 1. 

Knowledge Acquisition 

One of the interesting tasks in developing expert systems for many of the SSF is defining the 
controlling parameters and rule base. Unlike most traditional expert system development arenas a 
large portion of SSF applications represent new technology, therefore the domain of experts to pull 
working background information is very limited. To aid in this process certain standard guidelines 
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should be incorporated into system descriptions. The following is a list of guidelines which may 
be helpful in the task of knowledge acquisition (KA) for the ECLSS Software Support 
Environment (SSE): 

• SSE ought to provide standard protocols for the ways in which rules, frames and 
other representations should be written. Automated tools should be provided for 
indexing and using these elements. 

• Provisions ought to be made for the characteristics that must be provided for 
parameters and variables in KBS. 

• Documentation networks should be constructed that proceed at at least four levels. 

The working level of which the previous points would be a part, the experts 
consulted in the acquisition process and reports on the consultations, the 
specifications level as design is evolving and baselined, and supporting 
documentation 

• If a CLIPS like structure is used for the final product, then hooks should be 
provided through which the developer can attach the relevant KA and development 
items to the rule base. Although no such material will be uploaded, it should be 
available for future development work. This becomes even more critical, if there is 
no standard KB development environment. 

• In interview situations, a rough idea of the time window for the KB should be 
generated and posted in a public way. This would facilitate making informed 
decisions about scars. 


• Given the time window decisions should be made about the use of a specialized 
blackboard and the use of the distributed data base. If there is a significant need for 
a specialized blackboard structure, then one should be developed and made part of 
SSE. 


General Considerations 
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It is frequently preferable to use a commercially available software development shell to develop 
knowledge base systems (KBS). However presently there are only two such systems that it has 
been publicly announced that they will be converted into the mandated ADA programming 
language, CLIPS and ART. This may leave a void that will need to be filled in order to achieve the 
complete functionality of a satisfactory development tool. It is feasible to anticipate the future 
development of a totally new shell. Therefore, there are some general considerations that should be 
included in the SSE in order to minimize the amount of problems which could occur during KBS 
development and future updating by possibly differing shells. These are a sample of some of those 
general SSE considerations: 

• A standard protocol for expressing KB elements and procedures should be 
developed and placed in an automated tool, ideally to be included as part of the 
SSE. 

• A standard KB shell should be constructed for the development of KBS for SSF. 

It is to be recognized that in the near future the shell will have to deal with Ada, the 
mandated programming language. The shell should support both a development 
system and a run-time system. The development system will be limited to ground 
use. The run-time system will be available both on the ground and on the station. 

• Software switches should be incorporated that allow the KBS to be switched 
between confirmation modes in which the user can invoke the system to confirm an 
action, advisor modes which presents the user with the results of the inference for 
confirmation, and in-the-loop modes for autonomous operation. 

• The user model embedded in the KBS should be software switchable, or better 
self adjusting. In the early use of the system or when a new user must use the 
system a more instructional "flavor" should be presented to the user. As the user 
becomes more comfortable with the system either the system should retract 
instructional materials or the user should be allowed to select a more expert 
interface. 

• Facilities for explanation should be built into the system or the shell and the level 
of explanation available to the user should increase as the user becomes more expert 
and as the system approaches in-the-loop status. The instructional and explanatory 
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parts of the system are inversely related. When the system approaches in-the-loop 
status it will be important to generate clear consistent explanations on which the 
user can decide whether or not to override the system. 

• A KB system should provide hooks to a procedure engine if and when it is 
developed. A procedure engine is a software process that applies standing 
procedures for emergencies or maintenance to a specific circumstance. The 
procedure engine is in a sense an extended hypertext system. 

• The KB system should be integrated cleanly into the Standard Services and 
database system of the station. This may require hooks both in the KB system and 
in the Standard Services and database software. 

• Design the databases (RODBs) that service the specific units of the ECLSS 
software with slots for information exchange between units. For example, it 
should be possible to transmit information on status, diagnosis, and other inferred 
data from THC to WM for use in a KB at CHKSTA in P0TH20. 

• Specific hooks for the KB system to tap into the information in ECLSSERR and 
ECLSS PER should be developed. 

• Technology should not be blinded by the Ada mandate, and consideration should 
be given to the possibility of a LISP chip. This is especially so in KB technology 
since it is not unreasonable to think that research on knowledge systems will go 
forward in a LISP environment. If the effort is put into the use and production of 
more economical LISP machines, efficiency should increase while cost decreases. 

This will make the LISP machine look less exotic, and a potential additional 
processor for the Space Station. 

Cooperation and communication hooks 

The structural components of the ECLSS software support functions such as ECLSSERR and 
ECLSSPER must have access to data and message passing capabilities. This is an increasingly 
important and notably difficult problem since the RODB which is theoretically going to be a 
completely distributed onboard data base and the MODB which is at least initially going to be 
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ground based must be accessible from each level of the SSF software. The following items 
assume that there will be some CLIPS or CLIPS-like program to run the KBs. 

• Specific functions should be developed to read and write to the database. The 
these functions should fit neatly into a rule base paradigm, so that a rule of the 
form: 

If Read(sensor x) is greater 20, 

then write(Database_name, Database_element, "caution") 

The function should handle precommits, commits, and locks. 

• Functions should be developed to handle failures of database transactions. For 
example it should be possible to write rules such that 

If Database_failure(transaction_x), 
then retract(facts) and infer. 

• Provisions should be made for a rendezvous between KBs or other processes. In 
this case one might consider a rule 

If conditions a, b, c, 

then rendezvous(Process_name, data_element). 

• Provision should be made in the KB shell system for putting the system to sleep 
so that another more important task for the processor may be handled. For example, 

If Impt_message, 

then save(rules, facts) and sleep. 

The sleep command would be designed so that the rules and facts could be reloaded 
and execution resumed. 

• Provisions should be made so that the KB can send messages that will have 
greater or lesser importance. This would allow requests to be made to other 
processes that would force them up or down in the queue of requests. 

ECLSS specific hooks 

• The KBs in the ECLSS software environment should have access to ECLSSERR, 
ECLSPER, and history files. 
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• The KBs on the station should be constructed in such a way that they can be fit 
into the structure of commands, requests, and statuses. 

• The KBs in ECLSS should be constructed so that where appropriate the KB in 
one unit can have easy access to the KBs in other units. For example, it may be 
appropriate for the WRM to have knowledge of how much water is being produced 
by THC and how much it can anticipate to have. 

• In a cases where the user of the system wants to use the KBs as an assistant, 
appropriate modifications to DISPLAY ought to be developed to allow this. 

• Since any KB software for ECLSS will be in evolution during the life of the 
Space Station, KBs ought to be built with an eye toward their replacement. Ideally 
this would mean that Run-time Knowledge Base Engines (RKBE) would be in 
place on the Space and Station, and that modifications can be made to the KBs on 
the ground. New KBs could then be uplinked to the Space Station and replace 
existing ones. 

• Master Knowledge Bases (MKB) would be keep on the ground. Such MKBs 
would have access to data downlinked from the Space Station, as well as to 
development tools not present on the Space Station. 

• Hooks to the communications systems should be developed so as to allow the 
efficient distribution of downloaded materials to the appropriate facility, and to 
provide a central facility and standardized protocol for uploading new KBs. 


• Specific example 1: 

CHKSTA in P0TH20 gets inputs from PURIFY, STORAGE, QUALITY, and 
RECH20 and outputs control messages to each of these and reports status to 
ECLSSPER. Each of these are such that a knowledge based decision on the status 
of the unit may be needed. That is each of the units may vary from nominal in some 
way, but yet collectively be satisfactory. Each of the four units individually reports 
failure data to ECLSSERR. However, it should be noted that ECLSSERR only lists 
inputs from major subsystems, WRM in this case. The KB at the CHKSTA site 
might be important in terms of both horizontal and evolutionary development. 
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Concerning the former there are other units in ECLSS like CHKSTA. Concerning 
the latter what it is to be working well may change over time and the physical 
components being monitored may also change. If KBs can be updated like 
databases, then the task of updating the software for this unit will be greatly 
simplified. In point of fact it would simply be a case of file transfer. 


• Specific example 2: 

WRM is another ideal candidate. It contains P0TH20, H20QUAL, HYGH20. 
URINE, and WRMLIMITS. Oddly there seems to be no centralized unit that is the 
WRM. However, the following points should be noticed: (1) POTH20 and 
HYGH20 are very closely related in terms of both software and hardware and this 
argues for the use of P0TH20 as a site; (2) Both POTH20 and HYGH20 get 
information from H20QUAL and H20QUAL seems a natural site for a KBS; (3) 
The absence of a central monitor for WRM seems like either an omission or a 
mistake. 


• Specific example 3: 

ECLSSERR is a good candidate for KB technology. This is especially so since the 
ECLSSERR will have to separate critical and non-critical errors. IN the case of 
ECLSERR it will be important to have the full range of communication options 
available, as well as a large set of the valid ECLSS commands. This latter point will 
become more important as ECLSS approaches in-the-loop status. 


Potable Water Hooks and Scars 

The potable water portion of the WRM is, based on current design, a closed loop system that 
extracts condensate water from THC and water from the power generation system. It is not the 
purpose of this report to redescribe the entire working structure of any of the ECLSS subsystems, 
but rather to define ways to improve the daily operations of the subsystems by suggesting locations 
for automated computer assistance for the SSF crew. This section addresses the hooks and scars 
problem from a "systems" standpoint for the potable water loop. It is basically a list of possible 
faults and the instrumentation that might be necessary to make an automated KBS diagnosis. 
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Along with the general descriptions, a more specific "hardware" oriented schematic presentation is 
included. This is shown as schematic diagrams. Both of the current design and as a modified 
design which contains specific sensors necessary for the detection of faults . The current design 
diagram is based on the proposed potable loop configuration in figure 2.1 of the "Phase III CMIF 
Water Recovery System / Facility Design Requirements" by R. Bagdigian dated 8-4-88. 

(1) Input Loads Validation: 

Currently there is no evidence of verifying the condition of input loads to the 
system or even if input loads are within the design specifications. It is necessary to 
have a rough measure of how contaminated the input stream is to successfully 
diagnose faults. A great deal of time may be lost attempting to fix a system 
producing out of spec, product water when the input load is simply too great for the 
system design to handle. Even if input loads are within design limits this 
information is essential. Consider the following scenario. The water quality 
monitor at the terminus of the multifiltration subsystem indicates that process water 
is out of spec., but only slightly. In order to diagnose and form a fault recovery 
plan it is necessary to know whether the system is taking heavily contaminated 
water and removing 99% of this contamination to produce slightly out of spec, 
product or is the system removing only 2% of the contaminants from fairly clean 
input. In the first case, recirculation might fix the problem. However, in the latter 
case a specific class of contaminants may have fouled a particular sorbant in the 
unibeds and unibed replacement might be the only solution. This information will 
help trend analysis and a KBS answer questions like "Are the multifiltration system 
unibeds needing frequent change-out due to malfunctioning prefilters (or some 
other hardware cause) or is it simply extremely dirty input loads?" 

(2) Leak Detection: 

Several accurate flow meters are necessary throughout the loop in order to detect 
leaks and blockages. Attempting to detect leaks using only the flow totalizer will 
result in "manual" leak detection (i.e. short circuits and wet crew). 

(3) TOC, Iodine, and Water Quality Monitor Performance: 

A sensor of another type located at the same location can often give a rough estimate 
of the parameter in question to aid in monitor data validation. A conductivity meter 
in conjunction with the iodine monitor can help assess the performance of the 
MCV's. A certain amount of 12 introduced by the MCV's will exist in solution as 
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the ion l3‘ according to a fairly well characterized chemical equilibrium. The 
conductivity measured should correspond with the 12 measurement according to the 
physical laws governing I2/I3" equilibrium. Although other ionic contaminants 
would interfere to some extent, this method of validation may prove more reliable 
than trend analysis and more desirable both from a reliability and weigh/space 
saving than multiple sensor "voting". 

(4) Pumps: 

Flow and pressure sensors located immediately downstream from each pump are 
necessary to assess pump status (on or off) and performance. For example an ohm 
meter in the pump power circuit might indicate that the pump motor armature is 
turning and a KBS might decide that it is functioning properly when in fact a 
damaged impellor is not producing sufficient pressure of flow. With out this 
information it is impossible to assess whether a low flow/pressure condition is due 
to pump malfunction or line or valve blockage. 

(5) Heat Exchanger/Sterilizer Fouling: 

No temperature sensor has been included in the heat exchanger/sterilizer assembly 
to measure the temperature of the input stream. The delta T across the exchanger 
must be known in order to assess heat exchanger performance. A trend toward an 
increased temperature difference between input and output streams would indicate 
poor heat transfer and possible fouling or scale formation. Other causes would be 
insufficient dwell time in the exchanger due to too high a flow rate (data available 
from flow sensors mentioned earlier) or improper heater operation (data available 
from temperature sensors). 

(6) Valves: 

Several sensors in or near each control valve are necessary to report a valves 
condition (open or closed) in order to determine whether high pressure and/or low 
flow conditions are due to clogged filters, sorbants, or lines or simply a valve not in 
the proper condition. For instance, the controller might activate a relay to apply 
power to open a valve. The valve is faulty and does not open. Since the circuit is 
energized a conventional controller assumes the valve is open. With out valve 
condition verification, a KBS might conclude that some other blockage has 
occured. Note: this applies to any component which could be failed or blocked 
such as unibeds, strainers, MCV's, etc... 
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APPENDIX D - Dictionary 


AC 

Assembly complete -(used in growth configuration data book) 

ACD 

Architecture Control Document 
ACRC 

Assured Crew Return Capacity - (used in growth configuration data book) 
ACRS 

Advanced Carbon Reactor System 
ACS 

ATMOSPHERE CONTROL & SUPPLY SUBSYSTEMS 

* Pressure Control 

* Atmosphere Composition Control/Monitoring 

* Gas Storage 

* Vent and Relief 

ACTIVATE 

Activate Valid ECLSS Process 
AES 

Air Evaporation Subsystem 
AI 

Artificial Intelligence 
AR 

AIR REVITALIZATION SUBSYSTEMS 

* C02 Removal 

* C02 Reduction 
*02 Generation 

* Trace Contaminant Control 
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* Trace Contaminant Monitor 


ARG 

Air Revitalization Group 
ATTRIBUTE 

The data base model used on the space station depicts how command and data objects are named, 
created and how attribute information information about the objects is defined. For example, for 
Standard Services to read TOC sensor data into the RODB for potable water quality, Standard 
Services must know attribute information about addresses, conversions, and exceptions. 

BACK PORCH 

A truss extension on the Space Station which allows mobile servicing center access to the aft 
modules and provides additional structural support, depending on the module configuration. 

BACKWARD CHAINING 

Backward chaining is one of the ways in which a rule based system reasons. Backward chaining 
means that the inference engine will attempt to find the conditions that make a claim true. For 
example, suppose you believe that A is true, and that the system contains the following rules: 

If B and C then A 
if D then B. 

The backward chaining process would determine that in order for A to be true B and C would have 
to be true. Since D would have to be true in order for B to be true the system would try to establish 
the truth of D and C (and generally in that order). 

BMS 

Bed Molecular Sieve 
CELSS 

Controlled Ecological Life Support System 
CERV 

Crew Emergency Return Capability - (used in ref. 27) 

CETA 

Crew Equipment Translation Aid - (used in ref 27) 
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CFR 

Carbon Formation Reactor 


CHKSTA 

Monitor HYGH20 subsystem Statuses 
CLIPS 

CLIPS is a rule based shell for generating a knowledge based system in a C environment. C is a 
forward chaining system, although it can be "tricked" into a sort of backward chaining. CLIPS has 
strong pattern matching capabilities. As a shell, however, it has very few facilities that make life 
easy for the knowledge engineer. We will need to address this issue. 

CMD 

Verify and Validate ECLSS Commands 
CMG 

Control Moment Gyro - (used in ref. 27) controls Space Station guidance and navigation through 
active momentum management 

CMIF 

Core Module Integration Facility - 
CSS 

Customer Servicing Center - (from ref. 27) CSS is responsible for accommodating all Space 
Station servicing missions as will as supporting operations such as instrument and ORU storage 
and loading/unloading of the STS cargo bay. ..including accommodation, storage and servicing of 
the OMV, FTS, and SSRMS. Elements of the CSS include customer servicing facility, OMV, 
FTS, and components of the Canadian Mobile Servicing System including the mobile servicing 
center, SPDM, MMD, and MT. 

DDT&E 

Design, Development, Test, and Engineering. 

DISPLAY 
ECLSS Display 
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DMS 

DMS is the distributed database management system. DMS services can be divided into Data 
Management Services, Application Communication Services, Application Execution Services, and 
User Support Environment Services. 

ECLSS 

Environmental Control and Life Support Systems 
ECLSSERR 

ECLSS Fault Detection and Isolation 
ECLSSMGR 

ECLSS Manager, formerly ECLSS Support Software 
ECLSS PER 

ECLSS Performance and Trend Analysis 
EDC 

Electrochemical Depolarization Cell 
EDMT 

EXTENDED DURATION METABOLIC TEST 

Complete closure of the water loop will be addressed for the first time during the EDMT. 
Reclaimed hygiene water will be reused by test subjects for showers and handwashing. 
Additionally , subjects will ingest reclaimed potable water on a limited basis. 

ELV 

Expendable Launch Vehicles - (from ref. 27) 

EMM 

Evolution Mission Model - (used in ref. 27) 

EPS 

Electrical Power System 
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ES 

Expert System 


ESA 

European Space Agency - (used in ref. 27) 

ESSTAP 

Emulation, Simulation, Sizing, and Technology Assessment Program. NASA’s attempt to 
quantify the benefits that can be derived when an early emphasis is placed on software tools. 
Benefits expected are shortened development cycles, improved performance and resultant lower 
costs. The JRC's ECLSS-KBS project is a part of this broad program. 

EVA 

Extravehicular Activity - (from ref. 27) 

EVAS 

Extravehicular Activity Systems - (from ref. 27) 

EVOLUTION GROWTH BLOCK 

A group of incremental growth steps for several Space Station systems that will provide an overall, 
complementary increase in the Space Station's resources and capabilities., 

FDIR 

Failure Detection and Recovery 
FDS 

FIRE DETECTION AND SUPPRESSION SUBSYSTEMS 

* Fire Detection 

* Suppressant Storage 

* Suppressant Distribution 

FORWARD CHAINING 

Forward chaining is one of the ways in which a rule based system reasons. Forward chaining 
means that the inference engine will use new true claims and its rules to infer another true claim. 
For example, suppose that the system contains the following rules: 

If B and C then A 
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asserted then B 
Alternatively if 

FTS 

Right Telerobotic Servicer - (from ref. 27) 

H20QUAL 

Process Water Quality Sensor Data 

HAB 

Habitation 

HABOMA 

Habitat Operations Management Applications 
HAD 

Heat Acquisition Device - (from ref. 27) 

HEPA 

High Efficiency Particulate Air 
HYGH20 

Process Hygiene Water 
IESP 

Expert System Project 
INCO 

Integrated Communications Officer 
INHDATA 

Inhibited Function List 
INHIBIT 


if D then B. 

The forward chaining process would do nothing until a fact was asserted. If D is 
would be inferred, and if C had already been asserted then A would be concluded. 
B were asserted and C had already been asserted A would again be inferred. 
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Process ECLSS Inhibit Commands 


ISP 

Inter -vehicular Activity - (from ref.27) 

IWWMS 

Integrated Waste & Water Management System 
JSC 

Johnson Space Center 
KB 

knowledge based 
KBS GROUP 

Group of KB systems experts enlisted by NASA Space Station Level I Strategic Plans and 
Programs Division 

KNOWLEDGE 

Knowledge is stored in some representation and is used to direct the addition or deletion of 
elements from some fact base. Rules are a typical representation for knowledge. For example, a 
rule might claim that if the TOC is greater than a specified number, then shut down the process and 
notify the supervisor. 

KOH 

Potassium Hydroxide 
LAB 

Laboratory 

LAN 

local area network 
LARC 

Langley Research Center - (from ref. 27) 
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MCV 

Microbial Check Valve 

Not really a valve as it doesn't control fluid flow. Rather, it is supposed to control the "flow of 
microorganisms. Consists of a resin bed which provides about 2 ppm iodine to process waters for 
bacteriostasis. 

MF 

Multifiltration 

MMD 

Mobile Maintenance Depot - (from ref. 27) 

MMPF 

Microgravity and Materials Processing Facility - (from ref. 27) 

MODB 

MODB is the master object database manager. The MODB allows information about a devices 
MDM address, Engineering unit conversions, and exception condition parameters to be predefined 
into a configuration managed database that can be sent to a node. The MODB manager uses the 
predefined object and attribute information to build the RODB that allows Standard Services to 
configure its services to match the actual configuration of sensors, effectors, and derived data and 
command objects. 

MRDB 

Mission Requirement Data Base - (from ref. 27) 

MSC 

Mobile Servicing Center - (from ref.27) 

MSFC 

Marshall Space Flight Center 
MSS 

Mobile Servicing System - (from ref. 27) 

MT 
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Mobile Transporter - (from ref. 27) 


NSTS 

National Space Transportation System - (from ref. 27) 

OMA 

Operations Management Applications 
OMGA 

Operations Management Ground 
QMV 

Orbital Maneuvering Vehicle (from ref. 27) 

Proposed vehicle to boost Shuttle payloads to geosynchronous orbit. The vehicle would be based 
and serviced at the space station. 

ORU 

Orbital Replacement Units - (from ref. 27) 

OXONE 

OXONE - (tm) DuPont Corp. 

Proprietary dry chemical oxidizing compound, for industrial chemical synthesis.Active ingredient 
is Potassium monopersulfate. The active ingredient cannot be isolated in pure form so oxone is a 
mixture of KS03,KHS04, and K2S04. Aqueous solutions oxidize via a free radical mechanism 
possibly involving O. , X., and/or peroxydisulfuric acid. 

PATTERN MATCHING 

Pattern matching in knowledge based systems most often refers to the patterns of truth in the facts 
and rules of the system and the flexibility of their being matched. For example, suppose there is a 
term (T) that takes three arguments (a,b,c). Suppose that T(a b c) is true. One might only care 
about the value of one of the arguments, say b. Or again one might be interested in the values of 
two of the arguments, say a, c. A system with good pattern matching abilities would allow you to 
match in many ways, while weak pattern matching would allow only one way. 

P0TH20 
Potable Water 
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PURIFY 

Monitor and Control the Purification Process 


PVP 

Polyvinyl Pyrolidine 
PWMFS 

POTABLE WATER MULTIFILTRATION SYSTEM 

Used to recover potable grade water from a mixture of humidity condensate, C02 reduction by- 
product water, and C02 removal steam condensate. Consists of a system of 5 "Unibed" resin 
cartridges, pump, heat exchanger/sterilizer, and sensors. 

QCM 

Quartz Crystal Microbalance 
QUALITY 

Monitor the Water Quality 
R&D 

Research and Development 
RECH20 

Monitor and Control Receiving Tank and Pump 
RMOAD 

Reference Mission Operational Analysis Document- (from ref. 27) 

RO 

Reverse Osmosis 

RODB 

The Runtime Object Data base can be thought to exist at each node of the DMS. The RODB will 
contain the current values values for all currently available sensor and derived data item that 
originate at that node. Standard Services will provide location-transparent access to data in remote 
RODB's via directories built by the MODB manager. Sensor and derived data are written to the 
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RODB by the data supplier, and sensor and derived data can be read out of the data base by the 
users of the data. 


RULE 

Rules are one of the schema used to represent knowledge. A rule is composed of a left hand part 
that contains the conditions, and a right hand part that contains the actions. In forward chaining 
when the conditions are satisfied the actions are performed. In backward chaining if the goal 
matches an assertion of fact in the action side the engine will attempt to determine a value for the 
conditions. 

SAWD 

Solid Amine Water Desorbed 
SD 

Solar Dynamic - (from ref. 27) 

SDMS 

The Standard Services Data Management Services interfaces support applications access to the 
SSIS relational databases, SSIS files, and SSIS shared memory resident objects. It provides the 
services of a general purpose DBMS, including retrieve, add, change, and delete operations on 
single record or multiple records at a time. The on board DBMS will mange a centralized data base 
distributed across a network. 

Data base services include: 

LOGON, OPEN, SQL, DESCRIBE, NAME, DEFINE, BIND, EXECUTE, FETCH, 
COMMENT, COMMITOFF, COMMIT, COMMITON, ROLLBACK, ERRORMSG, CLOSE, 
LOGOFF, OPTIONS, RESUME. 

File management services include: 

CREATE, OPEN, CLOSE, DELETE, RESET, READ, WRITE. 

SFE 

Static Feed Electrolyzer 
SPDM 

Special Purpose Dextrous Manipulator - (from ref. 27) 

SPE 
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solid Polymer Electrolyte 


SSAA 

space station advanced automation 
SSDA 

Standard Services Data Acquisition provides both data and command functions. SSDA reads a'l 
sensor data that is defined on the local bus, and optionally converts raw data to Engineering units, 
saves values to RODB. and performs standard data processing services. SSDA also pertorms 
1553 bus I/O to MDM attached effector devices. Data acquisition is table driven. The tables can be 
considered to be in the RODB as built by the MODB manager. 

SSE 

Software Support Environment 
SSRMS 

Space Station Remote Manipulator System - (from ref. 27) 

STADIS 

Station Distributed System 
STANDARD SERVICES 

Standard Services provides data and command services for onboard core and payload systems. In 
this context data refers to sensor data, ADA application data, and UIL data. The last two items are 
called derived data. Commands refers to effector commands, requests to ADA application 
programs, and requests to UIL procedures. Standard Services allows local application programs to 
modify online some of the attribute information such as Engineering units or exception limit 
parameters of existing objects. 

STORAGE 

Monitor and Control Potable Water Storage 
STS 

Space Transportation System - (from ref. 27) 

STV 
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Space Transfer Vehicle - (from ref. 27) 


SWRS 

Shower Water Recovery System 
TBD 

To Be Determined - (from ref. 27) 

TBS 

To Be Supplied - (from ref. 27) 

TCCS 

Trace Contaminant Control Subsystem 
TCS 

Thermal Control System - (from ref. 27) 

THC 

TEMPERATURE /HUMIDITY CONTROL 
SUBSYSTEMS 

* Temp ./Humidity Control 

* Avionics Cooling Air 

* Process Air 

* Thermally Conditioned Storage 
TIMES 

Thermoelectric Membrane Evaporator System. Alternate to VCD for recovery of hygiene grade 
water from pretreated urine. 

TMP 

Trial Payload Manifest - (from ref. 27) 

TOC 

Total Organic Carbon 
TRRJ 
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Thermal Radiator Joint - (from ref. 27) 


TSA 

Test Support Accessory 
UIL 

UEL is the User Interface Language for the DMS. 

UNIBED 

Trade name for a commercial sorbents/exchange resin bed used to post-treat sterilized humidity 
condensate and C02 process water as a potable supply. 26.25" X 2.25" dia. 

Sorbent Media 
(in order of flow) 


MCV-H 

96 g. 

IRN-77 

90 g. 

IRA -68 

60 g. 

580-26 

600 g. 

APA 

95 g. 

XAD-4 

90 g. 

IRN-150 

90 g. 

MCV-H 

97 g. 

IRN-77 

90 g. 


URINE 
Process Urine 

VCD 

VAPOR COMPRESSION DISTILLATION 

The VCD subsystem is a candidate subsystem (along with the TIMES) for recovery of hygiene 
grade water from a pretreated urine/flushwater mixture. Subsystem operates on vacuum distillation 
principles. 

VPCAR 

Vapor Phase Catalytic Ammonia Removal 
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wcs 

Waste Collection System 
WM 

WASTE MANAGEMENT SUBSYSTEMS 

* Fecal Processing & Storage 

* Return Waste Storage 

WP -01 

Work Package 01 - (from ref. 27) 

WRM 

WATER RECOVERY AND MANAGEMENT SUBSYSTEMS 

* Potable Recovery 

* Hygiene Recovery 

* Urine Water Recovery 

* Water Quality Monitor 

WRMLIMITS 
WRM Limit Data 

WRMLMT 
Set WRM Limits 
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APPENDIX E - Report Software Description and Instructions 


The software that is to distributed with some of the reports is contained on two Macintosh™ 
diskettes. 

Diskette 1 contains the text of this report and many of the diagrams. The text is formatted tor the 
Microsoft Word™ 4.0 word-processing software. 

Diskette 2 contains two HyperCard™ stacks: Flows and Dictionary. 

The Flows stack contains a representation of the context flow diagrams that lead to the potable 
water subsystem. The stack can be started in the usual way, and all normal HyperCard™ functions 
are available. At the first card clicking on either the ECLSS Software Support unit or the WRM 
unit will take the user to the next card. Flows for the other parts of the ECLSS have not been 
implemented. The remaining cards contain a representation of the software unit in terms ot 
inputs/process/outputs. Clicking on any output term, takes the user to that output. In this way the 
user can trace the output. On many of the cards there is a "DETAIL" button above the process 
description. Clicking on this button presents the user with a more detailed account of the process. 
The process is again represented in input/process/output style, and clicking on the output term 
allows the user to trace the output. All of the text fields are unlocked and can be modified by the 
user. 

The Dictionary stack is a general dictionary stack with the ability to delete terms turned off. The 
Dictionary stack contains all of the terms in the dictionary section of this report. The stack can be 
started in the usual way. The stack has several ways in which the information can be accessed. 
Double clicking on any word or dragging on phrase in the entries selects it from the index. Click 
the FIND button to go to the card. When you are in a dictionary card selecting a word or phrase 
and clicking the REFERENCE button puts that word or phrase into the reference field of the main 
card. It can then be selected as any other item in the index field. While in a dictionary card, use the 
MAIN CARD button to return to the main card. Terms can also be browsed by first letter. Clicking 
on an alphabet button takes the user to the first dictionary card that begins with that letter. 
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ADD TERM brings up a dialogue that leads a user to the addition of a new term. WRITE sends the 
dictionary to an ASCII file for later processing. CLEAR removes the dictionary and compacts the 
stack. BUILD creates the dictionary stack from a file previously saved by a WRITE. This allows 
the user to maintain several dictionaries. Only one dictionary is included with this stack. 

In the Dictionary stack all of the fields are unlocked and indexes are maintained automatically. 
Altering the Dictionary Entries field directly will corrupt the index! 

The diskettes with these materials have been supplied to the following: 

Jim McKee — University of Alabama in Huntsville 
Dan Rochowiak — University of Alabama in Huntsville 
Brandon Dewberry — Marshall Space Flight Center. 
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HAB 47 
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Water Recovery and Management 77 

Water Thermal Conditioning 87 
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